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Preface 


Hie  purpose  of  this  thesis  effort  was  to  design  and  implement  a 
prototyjje  of  a  docunent  control  and  retrieval  system  which  could  be  used 
as  a  standard  system  by  Brazilian  Air  Force  Organizations.  The  system  is 
addressed  to  docimtents  exchanged  externally  among  Brazilian  Air  Force 
organizations  and  other  government,  civilian  and  private  orgamizations. 

The  diversity  of  formats,  standards,  and  kinds  of  documents  make 
such  a  sjrstem  a  challenge.  The  belief  that  it  can  significantly  improve 
decision  maJiing  atnd  assessment  has  motivated  me  to  accomplish  this  task. 

1  would  like  to  thank  my  thesis  advisor.  Major  James  Howatt,  who 
has  enriched  this  work  with  his  significant  conments  and  suggestions,  and 
my  committee  members,  Major  Mark  Roth  and  Prof.  Henry  Potoczny. 

I  wish  to  dedicate  this  work  to  my  loving  wife,  Vera,  for  all  the 
encouragement  and  support  she  has  given  me. 
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DCXJUMENT  CX»m»L  AND  RETRIEVAL  SYSTEM 
PC«  raE  BRAZILIAN  AIR  FtDRCE 

I .  Introduction 

Backjground 

In  this  thesis  the  term  docunents  refer  to  those  printed  reports 
sent  or  received  by  Brazilian  Air  Force  (BAF)  organizations,  that 
constitute  the  Brazilian  Air  Force  Official  Correspondence.  Because 
decisions,  requests  and  reports  are  the  essence  of  documents,  the  control 
and  organization  of  a  document  collection  has  become  as  inqportant  as  the 
decision  making  or/and  assessment  that  depend  on  researching  the 
collection.  The  use  of  digital  computers  profoundly  affected  the  field 
of  information  retrieval  by  permitting  the  mechanization  of  routines  and 
the  scanning  of  leu-ge  interdependent  files.  Because  of  the  high  costs 
involved,  until  few  years  ago  most  BAF  orgeinizations  could  not  afford  the 
computer  resources  necessary  to  run  such  systems.  As  a  consequence  of 
the  electronics  industry  revolution  that  has  been  made  microcoinputers 
more  powerful  and  cheaper,  BAF  organizations  can  now  afford  an  increasing 
number  of  microconqxiter  systems,  and  some  organizations  can  even  buy  such 
a  system  out  of  their  own  budget.  It  is  already  possible  to  take 
advantage  of  the  new  era  8uxi  improve  efficiency  suxi  speed  in  the 
classification,  control,  and  retrieval  of  docunents. 
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Problem  Statement 

The  probl^  addressed  in  this  thesis  will  be  the  development  of  a 
dociraent  control  and  retrieval  system  to  manage  Brazilian  Air  Force 
official  correspondence.  Tbe  system  is  intended  to  be  used  on 
microcomputers  as  standard  software  for  most  of  BAF  organizations. 

Scope 

This  thesis  presents  the  main  concepts,  the  design  and  the 
implementation  of  a  prototype  of  the  system  including  the  information 
retrieval  subsystem  that  uses  a  thesaurus  for  sesux^hing  by  subject.  The 
definition  of  the  terms  that  will  constitute  the  thesaurus  is  beyond  the 
scope  of  this  thesis,  although  the  structure  and  rules  to  define  them,  as 
well  8LS  the  tools  to  create  and  maintain  the  thesaurus,  eu%  given. 

The  procedures,  terms,  docimient  numbering  axxi  database  attributes 
comprise  the  standards  for  elaboration,  archive  and  elimination  of 
documents,  as  defined  by  the  "Instrucao  Sobre  Correspondencia  e  Atos 
Oficiais  do  Ministerio  da  Aeronautica,"  ICAER  (M.Aer. ,  1976),  and  by  the 
"Regulamento  para  a  Salvaguarda  de  Assuntos  Sigilosos,"  RSAS  (M.Aer., 
1977). 

As  the  official  correspondence  enconqpesses  classified  documents,  it 
is  assumed  that  the  system  will  be  operated  by  qualified  personnel  to 
which  are  granted  the  adequate  access  authorization.  It  is  possible  to 
limit  the  Eux:ess  to  the  system  or  peu:ts  of  the  system  by  using  passwords. 
It  is  even  possible  to  restrict  the  operation  to  a  certain  group  of 
activities  by  using  the  facilities  provided  by  the  Data  Base  Management 
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System.  Hiese  protection  actions  are  beyond  the  scope  of  this  thesis  and 
thus,  cure  not  presented. 

General  Approach 

Tbe  main  steps  followed  in  developing  the  system  were: 

a.  To  identify  significant  attributes  of  BAF  documents. 

b.  To  define  the  system  requirements. 

c.  To  review  the  literature  on  docunent  control  and  information 
retrieval . 

d.  To  review  the  literature  on  databeise  design. 

e.  To  review  the  literature  on  software  engineering. 

f.  To  choose  the  Database  MEtnagement  System  (DBMS)  for  supporting  the 
system. 

g.  To  establish  a  software  engineering  environment,  in  heu:Yiware  arid 
software,  to  support  the  system  development  effort. 

h.  To  design  the  relational  database  model. 

i.  To  implement  the  prototype  by  modules. 

j.  To  test  each  module  individually  arid  integrate  it  with  the  previous 
developed  modules. 

Sequence  of  Presentation 

The  ordering  of  the  steps  to  come  to  a  conclusion  is  not  always  the 
best  ordering  to  explain  that  conclusion.  The  sequeiice  of  presentation 
differs  a  little  from  the  ordering  used  to  develop  the  system,  but  I 
believe  that  doing  this  the  presentation  becomes  cleau^r.  Ihe  second 
chapter,  Requirements  Specification,  describes  the  desirable  behavior  of 
the  system.  In  that  chapter  the  system  is  decomposed  into  activities  to 
perform  the  necessary  functions.  Chapter  three  reviews  some  of  the 
theory  that  led  to  the  design  decisicxis  made  on  the  project,  mainly  on 


3 


the  database  design  and  on  the  choice  of  using  a  thesaurus.  Chapter  four 
presents  the  main  aspects  of  the  database  design,  vhich  was  modeled  using 
the  Entity-Relationship  Database  Model.  The  following  chapter,  mmiber 
five,  talks  adx>ut  the  implementation  of  the  model,  vhich  was  done  using 
the  Orau^le  RDBMS  for  MDOS  based  PC  microcomputers.  In  this  chapter  aure 
presented  some  of  the  fa^jilities  offered  by  the  Oracle  RDBMS,  like  the 
4th-generation  tool  to  generate  screen  forms.  Finally,  chapter  six 
concludes  the  work  evaluating  the  proposed  system  and  presenting 
recommendations  for  future  research. 


II.  Requirements  Specif icaticffi 


IntroductiOTi 

Before  presenting  the  requirements  specification  it  is  necessary  to 
clarify  some  important  concepts  as  v^ich  kind  of  docianents  the  syston  is 
expect  to  deal  with,  which  sectors  in  an  organization  are  concerned  with 
documentation,  what  is  expected  from  a  computerized  system  and  which 
procedures  of  the  manual  system  actually  in  use  are  important  and  must  be 
presetted  in  the  proposed  system.  Therefore,  we  present,  as  an 
introduction  to  the  specification  of  the  proposed  system,  a  brief 
overview  of  the  rules  and  procedures  ccwiceming  document  control  and 
retrieval  in  the  Brazilian  Air  Ministry,  and  some  of  the  advantages  of 
computerizing  the  manual  systan.  All  explanaticnis  are  based  in  the 
official  issues  of  ICAER  (M.Aer.,  1976)  eknd  RSAS  (M.Aer.,  1977). 

Following  this  oveirview  we  state  the  specif icaticm  of  the  proposed 
system,  which  is  divided  in  three  major  units,  and  identify  the  docunent 
attributes  that  will  constitute  each  unit.  Finally,  the  system  is 
decomposed  into  modules  to  accomplish  specific  functions. 

Document  Control  Overview 

Docunent.  The  Air  Ministry  Official  Correspondence,  that  is,  the 
correspondence  elaborated  by  or  sent  to  organizations  under  the  Air 
Ministry  or  Brazilian  Air  Force  Jurisdiction,  may  be  divided  into 
internal  and  external  docunents.  Internal  docunents  move  internally 
aiDcmg  the  sectors  of  the  same  organization.  External  docunents  are  those 
exchanged  among  Air  Ministry  organizations  or  amcxig  these  organizations 


5 


and  organizations  or  persons  that  are  not  under  the  Air  Ministry 
jurisdicticm. 

Protocol.  An  organization  has  two  sectors  that  are  directly 
concerned  with  docimentation ,  the  Protocol  and  the  Archive  sections.  The 
Archive  Section  is  introduced  in  the  next  paragraph.  Protocol  is  the 
dociment  register  and  delivery  section,  tdiich  is  responsible  also  for 
giving  to  the  users  information  about  dociments  and  doctment  management. 
For  each  docunent  that  is  sent  or  received,  the  Protocol  Section  keeps  a 
"Ficha  Protocolo"  (FP),  that  is,  a  Protocol  Card,  which  records  the 
docunent  movement.  The  FP,  which  is  typewritten  with  three  copies,  for  a 
total  of  4  versions,  contains  the  description  of  the  docunent 
characteristics.  Each  copy  is  kept  in  a  different  file  and  they  provide 
the  retrieval  of  docunents  by: 

1.  Protocol  Number 

2.  Originator 

3.  Name  of  a  person  related  to  the  docunent 

4.  Subject  (one  line  sunnary  of  the  docunent) 

An  organization  may  have  two  Protocol  Sections,  one  for  public  docunents 
and  the  other  for  classified  docunents.  Classified  docunents  demand  some 
supplementary  procedures,  as  a  docunent-received  conf irmaticxi  from  the 
addressee,  and  sometimes  use  a  more  sophisticated  subject  retrieval, 
usually  based  on  a  list  of  subjects. 

Archive.  Archive  is  the  docunent  repository  secticwi.  It  is 
responsible  for  organizing  the  docunent  collection  in  such  a  way  that  it 
can  be  easy  consulted,  there  are  three  levels  of  Archive: 

-  of  an  internal  Department  or  Division; 

-  of  an  Organization; 

-  of  the  Air  Ministry. 
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In  this  effort  we  are  mainly  concerned  with  the  Archive  of  an 
Organization.  Table  I  shows  which  types  of  dociments  are  kept  in  an 
organizaticNi. 


Table  I.  Docimients  Kept  in  an  Organization’s  Archive 


Permanently: 

originals  of  Organization’s  Bulletin; 
docvraents  with  historical  value; 
personnel  records ; 
documents  related  to  Justice; 

documents  related  to  Instructic»i  (for  schools,  academies, 
institutes,  etc); 

other  documents,  chosen  by  the  comnander. 

For  10  yeaurs: 

docimients  related  to  permanent  material. 

For  5  years: 

docimients  related  to  finances; 

-  copies  of  documents  sent  to  other  organizations; 

-  docisnents  related  to  discipline; 

received  docimients,  definitely  solved,  vhich  are  not  expected  to 
be  consulted  again 


Docunent  Destruction.  A  comnissicxi  composed  by  three  members  is 
designated  yearly  to  select  among  the  docimients  in  the  files  those  idiich 
should  stay  in  the  Archive,  those  to  be  sent  to  the  Air  Ministry  Archive, 
or  those  to  be  destroyed.  Ihe  decision  is  posted  on  the  docimient  cixitrol 
card.  The  procedure  for  classified  docimients  is  regulated  by  the  RSAS 
(M.Aer. ,  1977b),  but  is  essentially  the  same. 

Microfilmed  Docimients.  Microfilm  process  is  used  whenever 
possible.  The  dociments  to  be  translated  to  microfilm  are  those  selected 
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to  be  kept  permanently  and  for  10  years.  Doctments  of  historical  value 
cannot  be  destroyed,  even  after  they  have  been  microfilmed.  Microfilms 
should  be  organized  to  permit  the  same  kind  of  retrieval  that  is  done 
with  docun^ts  in  paper  form. 

What  to  Expect  from  the  Automated  Sjrstem 

One  could  argue  that  it  is  not  necessary,  nowadays,  to  discuss  the 
benefits  of  automation  because  everybody  knows  that  computers  do  it 
faster.  I  agree!  The  problem  is  v4iy  should  we  take  the  always  limited 
resources  we  have,  to  computerize  the  doctment  control  system  instead  of 
some  other  not-automated-yet  system.  Is  it  important?  How  much  time  and 
manpower  an  automated  system  might  save? 

It  is  not  possible  to  give  precise  numbers  that  represent  the  gain 
without  having  two  real  systems  to  contrast,  llie  compeirison  depends  on 
various  parameters  of  each  system  being  compeired.  In  spite  of  not  giving 
final  nxjnbers,  we  can  present  various  eepects  and  facilities  of  both 
systems,  to  permit  the  reader  come  to  his  own  ccmclusions .  Ihe  remarks 
about  manual  and  automated  systems  for  docunent  control  are  personal 
viewpoints  derived  from  an  experience  of  ten  yeeus  working  in  tasks 
related  to  docunent  management  in  the  Brazilian  Air  Force. 

Control .  One  of  the  most  important  advanteiges  of  the  computerized 
system  is  the  control  over  the  docunentaticxi  being  processed.  Once  the 
criteria  of  stability  was  defined,  that  is,  the  average  time  to  process 
kinds  of  docunents,  it  is  easier  to  detect  instability  and  to  take 
corrective  actions.  Ihe  manual  system  offers  inadequate  ccxitrol.  As  an 
example,  to  find  a  docunent  that  has  never  reached  the  Archive  Section  we 
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have  to  follow  the  document  track  from  its  first  destination  to 
depeurtmoits  and  sections  through  which  it  might  eventioally  have  passed. 
Another  difficulty  of  the  manual  system  is  choosing  which  documents  from 
the  collection  have  to  be  destroyed.  Deciding  vAiich  documents  are 
"definitely  solved,  and  not  expected  to  be  consulted  again"  is  a 
challenging  task.  Because  of  the  inherent  retrieval  faw^ility  offered  by 
computerized  systems,  it  is  possible  to  give  a  "validity"  attribute  to 
each  docvnient  that  makes  easier  a  future  decision  about  its  destruction. 

Standardization.  A  standard  system  offers  the  possibility  of  easy 
comnunication  between  distinct  systans.  It  would  be  possible  exchange 
docixnents  in  computer  file  form  between  organizations,  taking  advanteige 
of  the  same  kind  of  management,  recording,  and  retrieval.  This  would 
represent  a  tremendous  savings  in  perscHinel  instruction,  software 
development  effort  and  time. 

Manpower.  When  a  manual  docunent  control  system  is  automated  the 
personnel  staffing  is  not  likely  to  be  reduced  for  two  reasons: 

-  usually  the  staff  was  insufficient  to  do  all  the  tasks  it  was 
supposed  to  do.  The  automated  system  fills  the  gap. 

-  new  facilities  offered  by  the  automated  system  and  the  completion 
of  tasks  which  were  not  accomplished  before  absorb  the  manpower 
that  would  be  saved. 

Time.  The  following  example  gives  an  idea  about  time  saving  in  an 
automated  system.  Correspondence  arrival  is  not  smoothly  distributed, 
the  regulau*  official  mail  comes  twice  a  day.  Depending  cm  the  size  of 
the  organizaticm,  the  Protocol  Section  is  overloaded  in  these  occasions. 
Meiybe  important  informaticxi  or  \jrgent  decisions  have  to  wait  for  the 
protocol  processing.  In  the  manual  system,  for  each  document,  the 
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Protocol  has  to  typewrite  data  on  a  protocol  card  (four  copies)  and  on  a 
processiiig  sheet.  Suppose  that  the  same  data  is  to  be  entered  in  the 
computerized  system  using  a  keyboard  and  a  terminal  display,  and  that  the 
processing  sheet  is  printed  by  a  printer  connected  to  the  computer.  If 
we  assume  that: 

a  -  the  data  about  each  docunent  suns  180  characters  on  average 

b  -  the  operator  types  180  characters  per  minute  in  average  (typewriter 
or  keyboard) 

c  -  the  time  to  change  and  adjust  a  protocol  card  in  the  typewriter  is 
30  seconds 

d  -  the  time  to  change  and  adjust  a  processing  sheet  in  the  typewriter 
is  30  seconds 

e  -  the  printer  prints  at  180  characters  per  second 

f  -  the  time  to  change  and  adjust  a  processing  sheet  in  the  printer  is 
5  seconds  (it  is  automatic) 

g  -  the  operator  does  not  make  any  otistakes  entering  the  data 

h  -  the  Protocol  Section  receives,  at  the  same  time,  40  docunents  to  be 

processed 

i  -  the  work  is  done  by  only  one  operator  in  either  systems 

Processing  the  40  docunents  in  the  manual  system  would  take  2  hours: 

Typing  protocol  cards:  (h  »  a)  /  b  =  40  *  180  /  180  =  40  minutes 

Typing  processing  sheets:  (h  *  a)  /  b  =  40  *  180  /  180  =  40  minutes 

Changing  protocol  cards  on  the  typewriter:  c  *  h  =  0.5  *  40  =  20 
minutes 

Changing  processing  sheets  on  the  typewriter: 
d  *  h  =  0.5  *  40  =  20  minutes 

In  the  automated  system  the  same  task  would  take  0.73  hours: 

-  Entering  the  data  on  the  keyboard: 

(h  *  a)  /  b  =  40  *  180  /  180  =  minutes 

-  Printing  the  processing  sheets: 

(e  t  f)  *  h  =  Isec  -f  5sec  *  40  s  240  sec  =  4  minutes 
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A  very  iiqxirtant  and  time  ccxisimintf  task  was  not  taken  into  account.  In 
the  nEoiual  system  we  still  have  to  insert  each  copy  of  the  protocol  cards 
in  four  different  files,  in  alphabetical  order.  This  totals  160  cards 
that  have  to  be  properly  arranged.  How  much  time  does  it  takes?  If  it 
takes  about  30  seconds  to  file  each  copy,  this  extra  work  will  take  1 
hour  and  20  minutes.  How  many  mistakes  8u*e  comnitted  in  this  task? 

Reliability.  Rigid  and  controlled  structure  is  one  of  the  most 
important  characteristics  of  a  computerized  system.  There  is  no  threat 
of  informal  changes  introduced  in  the  system  by  users.  There  are  means 
to  validate  entry  data  in  order  to  reduce  hunan  errors.  Once  the  entries 
are  correct  the  data  manipulation  does  not  corrupt  information  stored  in 
the  database.  Retrieval  is  less  human  dependent.  We  can  browse  the 
collection  in  numerous  ways  to  erasure  that  no  docvanentation  stays 
forgotten,  inaccessible,  lost  in  the  stacks. 

Resistance.  Some  resistance  in  accepting  the  new  system  is 
expected.  Opposition  usually  is  for  unconscious  reasons.  Behind  the 
antagonism  there  is  a  feeling  of  loss.  Persons  vAio  used  to  be  cxxisulted 
about  docvments  feel  unimportant  anymore  because  looking  for  a  docunent 
was  made  easy.  Delays  and  incorrect  handling  are  soon  detected  stnd  people 
feel  they  aure  being  audited.  Explanaticxis  about  the  system  and  its  goals 
are  the  solution  to  the  mjority  of  resistance  problems. 

General  Design  Specification 

According  Pressman  (Pressman,  1987:152),  because  specifications  are 
the  description  of  "what",  rather  than  "how",  they  can  take  the  form  of 
mathematical  functions:  "given  some  set  of  input,  prodvice  a  particular 
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set  of  outputs."  Using  this  kind  of  description  we  present  the  desired 
system  as  follows: 

Given  a  set  of  identifiers  that  denotes  a  document,  the  most 
frequent  questions  made  about  administrative  docunents  are: 

-  Has  the  organization  received  this  document? 

-  What  is  this  document  about? 

-  Where  is  this  document? 

-  Which  sect ions /departments  have  already  processed  this  document? 

-  Wiio  is  currently  analyzing  this  document? 

-  Which  docunents  may  I  destroy? 

Less  frequent  than  the  previous,  but  not  less  important, 
the  following  question  arises: 

-  Which  documents  are  related  to  this  subject? 

Figure  1  shows  a  typical  administrative  document  routine  for 
Brazilian  Air  Force  organizations.  The  Protocol  Section  enters  the 
docunent  description  in  Protocol  Cards  and  prepares  a  Processing  Sheet 
(PS)  that  contains  data  about  the  document  identification.  Ihe 
processing  sheet  is  attached  to  the  document.  The  Comnander,  or  a  person 
designated  by  him,  decides  which  department  or  section  the  document  will 
be  sent  to;  this  is  explicitly  placed  on  the  PS.  The  Protocol  Sectitxi 
sends  the  document  to  the  referred  department  or  secticxi.  If  it  is 
necessary,  the  former  department  sends  the  docum^it  to  another 
depeurtment.  After  processing,  the  docviment  is  sent  to  the  Archive 
Sectim.  In  the  processing  phase,  occasionally,  documents  are  Joined  to 
each  other  to  form  a  single  document.  Briefly,  these  are  the  main  steps 
involved  in  the  administrative  docunent  routine. 
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Fitfure  1.  Docunent  Flow  Qiart. 

TTie  Archive  Section  woriia  as  a  library  and  keeps  the  whole  document 
collection.  Departinents  and  secticxis  borrow  dociments  from  the  Archive. 
In  the  Archive  Section,  documents  may  stay  in  paper  form  or  may  be 
recorded  on  microfilm.  Periodicedly,  useless  dociments  are  selected  to 
be  destroyed. 

To  answer  those  questions  about  administrative  docuaents,  the 
proposed  system  has  manual  and  computerized  procedures  that  involve  the 
registering,  distributicm,  processing,  retention,  archive  and  destruction 
of  dociments,  each  one  contributing  to  form  a  knowledge  base  about  the 
doctmimt  collection.  This  knowledge  bsise  is  logically  subdivided  in 
three  parts: 

Catalog  Database 

-  Subject  Database 

-  Control  Database 
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We  may  thin£  about  the  system  in  an  object-oriented  manner  where  a 
docuoent  is  the  principal  object.  The  logical  division  of  the  database 
reflects  that  we  are  mainly  interested  in  three  aspects  of  docunents: 

-  The  Catalog  view,  which  gives  us  the  identification  of  a  document 
based  on  its  characteristics;  we  can  call  these  characteristics 
"header  attributes". 

-  The  Subject  perspective,  that  classifies  doctments  by  their 
contents,  that  is,  by  the  issues,  themes,  topics,  or  informaticxi 
addressed  on  them. 

-  Finally,  the  Control  perceptitm,  which  gives  information  about 
the  docimient  processing  stage,  the  department  or  section  that  keeps 
the  document,  the  person  who  is  handling  it,  etc... 

The  two  first  databases  are  concerned  with  different  kinds  of 

docvmjent  retrieval  and  the  last  one  with  the  docunent  ccmtrol.  In  the 

following  section  the  attributes  that  constitute  the  Catalog  and  Control 

Databases  are  presented.  The  attributes  which  form  the  Subject  Database 

are  introduced  on  the  section  about  Thesaurus  theory. 

Document  Attributes  Identification 

By  docvmient  attributes  we  do  not  mean  only  those  that  are  written 
in  the  header  or  body  of  a  docunent,  but  also  those  that  are  used  to 
identify  or  control  the  docunentation .  Some  of  them  are  found  in  the 
Processing  Sheet,  the  paper  attached  to  a  received  docunent  by  the 
Protocol  Section,  others  may  be  written  in  a  "despacho"  (dispatch, 
process)  cover,  which  is  a  kind  of  a  docunent  that  is  a  join  of  other 
docunents  necesseiry  to  answer  or  clarify  a  same  question  or  subject. 
Explanaticxis  will  be  given  whenever  necessary  to  clarify  the  meaning  of 
an  attribute. 
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Catalog  Database.  Tlie  catalog  database  is  composed  of  all  files 
that  together  store  the  docvinent  characteristics,  generically  called 
"header  attributes."  TTiese  attributes  are  listed  in  Table  II  and  defined 
in  the  next  paragraphs. 


Table  II.  Header  Attributes. 


Protocol  Nunber 
Docunent  Identification 
Docunent  Reference  Nijnber 
Organization  Name 
Issuing  Date 
Title 

Document  Type 
Classification 
Reference 
Annex 


Protocol  Ntjnber.  The  Protocol  Number  (FRDT)  is  one  of  the 
major  means  of  document  identification  in  the  Brazilisun  Air  Ministry. 

Iliis  number  is  assigned  to  a  document  by  the  issuing  organization  euxl  no 
further  numbering  is  permitted,  even  when  a  receiving  organization 
forwards  the  document  to  other  organizations.  It  is  coiiQ»sed  of  three 
peurts:  an  Organization  Code  (P_CX®E),  a  sequential  number  (P_NUMBEE),  and 
the  two  last  digits  of  the  current  year  (P_YEAR) .  The  peu'ts  are  sepeurated 
by  slashes.  The  PJDODE  is  formed  by  the  superior  cooraand  code  (P_SC)  and 
by  the  organization  code  (P_OC),  vixich  are  sepeuTated  by  a  bar  (99-99). 

Figure  2  shows  an  example  of  a  protocol  nunber.  In  a  document, 
this  number  is  always  preceded  by  the  initials  "Proc" .  Air  Ministry 
organizaticxis  vhich  do  not  have  the  organization  code  (P_OC)  substitute, 
on  a  temporary  basis,  the  code  by  the  organization  initials.  Any 
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Proc  Nr  10-01/453/88 


Figure  2.  Protocol  Number. 

docuDient  received  by  Brazilian  Air  Ministry  organizations  that  does  not 
have  the  protocol  nimber  is  numbered  by  the  receiving  organization.  Each 
docvment  has  only  one  protocol  number,  from  its  issue  to  its  final 
archive,  even  if  it  heis  been  sent  to  several  organizations  in  different 
years  (M.Aer. ,  1976:7-1,7-2).  Classified  docvments  have  an  independent 
sequential  ortiering  for  each  classification  level. 

Document  Identification.  The  docvment  identification  is  an 
alphanvmeric  identification  given  to  a  docvment  by  the  issuing 
organization.  Ibis  identification  may  be  subdivided  in  a  vsu'iable  number 
of  fields,  each  one  with  a  different  meeming.  The  segmentation  and  the 
meaning  of  each  part  vary  among  organizations.  Tbese  variations  make 
difficult  the  use  of  the  docvment  identification  attribute  as  a  searching 
key.  Since  all  variations  have  a  coomon  point,  -  a  sequential 
identification  number,  this  number  is  extracted  from  the  docvment 
identification  and  used  isolated  as  a  searching  key.  All  other  parts 
together  constitute  an  identificaticxi  cooq^lement  to  differentiate 
documents  with  a  same  identification  nvmber. 

-  Identification  Number  -  II^ 

-  Identification  Ckmplement  -  IDOOMPL 

Figure  3  shows  the  placement  of  the  identification  nvmber  and  complement 
on  a  docvment.  Different  docvments,  even  from  the  same  organization, 
might  have  duplicated  II^{R.  Ibis  typically  occurs  vdven  each  Department 
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Figure  3.  Identification  Nijnber  and  Complement. 

in  the  same  organization  eissigns  its  own  number.  Usually,  the 
differentiation  is  made  by  the  Department  initials  in  the  IDOOMPL. 

Docvjnent  Reference  Number.  The  DRN  is  a  con^xjsite  nianber 
given  to  a  document  by  the  Archive  Section.  It  is  formed  by: 

-  the  year  of  registering 

-  the  origin  code  ("1"  received  documents,  "2"  sent  document) 

-  the  sequential  number  under  each  of  the  previous  nuanbers 
The  document  collection  is  physically  organized  in  the  Archive 

Section  by  this  number,  making  easy  the  physical  document  retrieval. 
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Orgainization  Name.  ORO<iAME  is  the  short  name  of  the 


organization  that  has  issued  the  document.  There  must  be  an  unique  name 
for  each  organization. 

Issuing  Date.  ISSUEDT  is  the  date  when  the  document  was 
issued.  Issuing  date  euvi  organization  name  together  constitute  an 
important  key  for  an  empiric  retrieving,  browsing  a  set  of  documents 
issued  by  a  certain  organization,  during  a  given  period  of  time. 

Title.  TTie  TITLE  of  an  administrative  document  usually  is  an 
outline  of  the  Docianent  subject.  This  title  does  not  have  the  same 
meaning  els  a  bibliograjAiic  or  technical  docimient  title.  It  is  not 
unusual  to  find  several  documents  with  the  same  title. 

Document  Type.  The  BAF  deals  roughly  with  40  types  of 
document  -  DOCTYPE.  Most  of  them  are  sporsuiically  used.  Some  of  the 
most  used  documents  are  shown  in  Table  III. 

Classification.  Concerning  the  distribution  -  CLASSIF, 

documents  are  considered  public  or  classified.  The  public  official  issue 

that  establishes  special  procedures  applied  to  classified  documents  is 

the  "Regulamento  para  a  Salvaguarda  de  Assuntos  Sigilosos”  -  RSAS 

(M.Aer,,  1977).  It  divides  classified  docvonents  in  Reserved, 

Confidential,  Secret  and  Ultra-Secret.  As  the  details  of  each 

classification  are  not  in  the  scope  of  this  thesis,  we  will  not  discuss 

them  here.  The  procedures  for  claissified  docvnents  will  be  presented 

vdienever  it  becomes  necessary.  Tbe  proposed  system  is  intended  to  mana^ge 

three  of  the  cleissification  levels; 

P  -  public  or  unclassified 
R  -  reserved 
C  -  confidential 
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Table  III.  Some  Types  of  Document  used  by  the  BAF. 


Docvnent  Name 


Translation 


Apreciacao 

Despacho 

Encaminhamento 

Estimativa 

Informacao 

Oficio 

Relatorio 

Relatorio  Especial 

Relatorio  Periodico 

Requerimento 

Boletim 


Analysis 

Process,  join  of  docunients 

Doc.  listing  eind  introduction 

of  other  documents 

Estimating 

Information 

Officio 

Report 

Special  Report 
Periodic  Report 
Request 

Organization’s  Bulletin 


Reference.  Some  documents  may  refer  (REFER)  to  other 
documents  for  various  reasons.  The  organization  may  or  may  not  have 
received  the  referenced  document.  Tbe  reference  itself  can  be  a  DocLinent 
Reference  Number,  a  Protocol  Nunber,  a  Document  Identification  or  another 
alphanumeric  string. 

Annex.  Documents  may  have  a  supplement  attached  to  it.  This 
supplement  is  called  "Anexo"  (ANNEX).  Ibis  attribute  describes  in  words 
the  writing  attached  to  the  document. 

Control  Database .  As  the  name  indicates,  the  control  database  is 
related  to  the  dociment  control  and  to  the  actual  phase  of  docunent 
processing.  Hie  attributes  identified  in  this  base  the  following: 

Validity.  The  interest  about  most  administrative  documents 
decre8ises  with  time.  Some  documents  are  of  ephemeral  importance  and 
become  of  no  interest  very  fast.  As  a  consequence,  unlike 
bibliographical  techniques,  we  will  be  interested  in  destroying  these 


useless  docunents  that  occupy  space  in  the  Archive  Section.  VAien  a 
document  is  cataloged  in  the  system  it  automatically  receives  a  validity 
date  (VALIDITY) ,  that  consists  in  the  date  to  which  the  docvinent  is 
considered  of  importance  (valid).  Ihis  automatic  assignment  is  made  for 
a  five  year  period,  based  cm  the  dociioent  Issuing  Date.  Ihe  docunent 
analyst,  when  processing  the  docunent,  may  request  to  change  the  validity 
date.  The  request  is  written  twi  the  processing  sheet  and  processed  by 
the  Archive  Section. 

Docunent  History.  The  docunent  history  expresses  the 
processing  for  which  a  docunent  has  passed.  It  is  composed  of  two  peurts: 
the  docunent  log  and  the  actual  holder.  The  docunent  log  is  a  set  of 
attributes  chronologically  arranged  in  a  table  vAiich  reflects  the 
docunent  processing. 

DATE  -  Delivery  date 

TIME  -  Delivery  time 

SEND_DEP  -  Sending  department  or  section  Initials 

RECJpEP  -  Receiving  department  or  section  Initials 

The  holder  information  is  composed  of  the  holding  department  code  and  the 
holding  person  name  as  follows: 

DEPOODE  -  Department  code 

NAME  -  Name  of  vho  is  processing  the  docunent 
Too  much  control  tends  to  slow  down  the  docunent  processing  speed.  From 
a  centralized  control  overview  it  is  enough  to  determine  in  vAiich 
Depeirtment  the  docunent  actually  is.  Therefore,  the  name  of  the  holder 
is  an  accurate  control  to  be  optionally  used  by  a  Department  as  an 
internal  control,  vAienever  the  depeu'tment  has  its  own  computer  terminal. 
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Hie  docunent  history  is  updated  when  the  docunent  is  sent  from  one 
Department  to  another  one.  Hie  information  for  this  update  is  extracted 
from  a  transference  receipt. 

Docunent  Status.  Hie  docunent  status  represents  the  document 
situation  related  to  the  following  conditions: 

JOINSTS  -  Join  Status 

J  -  Joined.  Hie  docunent  was  joined  to  another  one.  In  this  situation 
it  does  not  have  its  own  docunent  history.  Hie  history  of  a  joined 
docunent  is  the  same  as  the  history  of  the  principal  docunent,  that 
is,  the  docunent  to  which  it  was  joined. 

M  -  Main  docunent.  Other  docunent (s)  has(ve)  been  joined  to  this 
docunent . 

I  -  Independent.  Hie  docunent  has  its  own  docunent  history. 

FWXSTS  -  Processing  Phase  Status 

P  -  Processing.  Hie  docunent  is  being  processed.  It  is  automaticsdly 
given  by  the  system  vrfien  the  docunent  is  entered. 

W  -  Waiting.  Unpi'edictable  delay  on  the  document  solution  or  unsolved 
docunent. 

S  -  Solved. 

PORMSTS  -  Document  Form  Status 

P  -  Paper. 

M  -  Microfilm. 

F  -  Computer  File. 

D  -  Destroyed.  Hie  docunent  has  been  destroyed. 

HISTSTS  -  Document  History  Status 

A  -  Alteration.  An  anomaly  or  inconsistency  was  detected  in  the 
document  history. 

N  -  Normal. 


ARCHSTS  -  Responsible  Archive  Secticm  Status 

C  -  ClEissified  Archive. 

U  -  Ifticlassified  Archive. 

To  know  whether  a  docunent  is  filed  in  the  classified  archive  or  in  the 
uiclassified  archive  it  is  not  always  enough  to  know  the  docunent 
classification  level.  Although  a  classified  docunent  will  never  be  filed 
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in  the  unclassified  archive,  the  inverse  may  happen.  If  an  unclassified 
docunent  is  Joined  to  a  claissified  one  the  whole  docvraent  becomes 
classified.  A  controversy  arises  whether  the  unclassified  part  should  or 
not  be  officially  declared  classified.  The  Archive  Status  solves  this 
uncertainty  by  fi^iving  the  exeunt  direction. 

Microfilm  Indexing .  When  the  docxmient  has  been  microfilmed, 

the  kind  of  film  and  frame  identification  are  recorded.  They  might  have 

more  than  one  microfilm  record  related  to  each  docixnent  because  frames 

are  not  in  sequence  or  are  in  distinct  films.  The  database  attributes 

are  sis  follows: 

FJTYPE  -  Type  of  film 

F_NO  -  Film  number 

FIRST  -  Initial  frame  number 

LAST  -  Last  frame  number 

Join  Indexing.  When  docvments  have  been  joined,  vAiich  is 

indicated  by  the  Join  status,  there  is  a  list  that  relates  the  main 

document  to  the  document (s)  that  has (have)  been  Joined  to  it.  On  this 

list  documents  are  referred  8is: 

MAINDOC  -  the  main  docimient 
JOINED  -  the  Joined  docijnient(s) 

Verifier.  VERIFIER  is  a  control  attribute  created  to  protect 
against  wrong  docunent  updates.  It  is  used  in  update  screens  that  do  not 
display  the  catalog  data,  tdiich  oekes  difficult  the  docunent 
identification.  Its  computation  was  derived  from  a  Division  Hash 
Function  where  we  consider  the  verifier  as  the  resulting  address  for  a 
KZN  key.  The  original  hash  function  was  slightly  modified  by  taking  the 
MIN  to  the  second  power,  to  provide  no  consecutive  verifiers  for 
consecutive  DRNs.  Figure  4  shows  the  original  functicxi,  the  Verifier 
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Hash  Functicm: 

F(X) 

=  X  mod  M 

Verifier 

Function: 

Ver(E«N) 

=  mod(DRN^2,97) 

RECEIVE 

SEND 

DRN 

VERIFIER 

I»N 

VERIFIER 

89100001 

8 

89200001 

61 

89100002 

50 

89200002 

89 

89100003 

94 

89200003 

22 

89100004 

43 

89200004 

54 

89100005 

91 

89200005 

88 

89100006 

44 

89200006 

27 

89100007 

96 

89200007 

65 

89100008 

53 

89200008 

8 

89100009 

12 

89200009 

50 

89100010 

70 

89200010 

94 

Figure  4.  Verifier  Function. 


Function,  and  some  EKlNs  with  corresponding  Verifier  values.  "M"  was 
chosen  as  97,  vAiich  is  the  highest  two  digit  prisie  number,  giving 
verifiers  in  the  range  0  to  96.  The  choice  of  a  prime  number  is 
suggested  by  Horowitz  (Horowitz,  1987:456,457).  Tbe  Verifier  is  printed 
on  the  Processing  Sheet. 

Modular  ftirtition 

There  are  various  analysis  methodologies  that  enable  an  analyst  to 
apply  fundamental  analysis  principles.  According  Pressman  (Pressman, 

1987 : 164 ) ,  all  methods  have  the  comnon  characteristics  of  permitting  a 
function  representation,  definition  of  interfaces,  mechanisms  for  problem 
partitioning,  support  for  abstraction,  and  representaticm  of  physical  and 
logical  views.  Structtired  Analysis  and  Design  Technique,  SADT  (registered 
trademeuic  of  SofTech,  Inc. )  is  a  comprehensive  methodology  for  doing 
functicHial  analysis  and  system  design.  It  is  beyond  the  scope  of  this 


woz4i  to  detail  this  technique  but  its  fairly  strict  syntax  permits  a  good 
understanding  of  the  system  decomposition  without  deep  explanations. 

Ibis  modeling  technique  encompasses  a  series  of  hierarchically  related 
function  diagrams.  It  is  used  in  this  work  to  capture  the  system 
decomposition  from  the  user  viewpoint  and  to  give  us  a  first  insight  of 
modules  interaction. 

The  Environment  Level  Diagram.  The  environment  level  diagram  shown 
in  Figure  5  is  the  system  highest  level  diagram.  It  shows  the  interewition 
of  the  system  with  the  world.  On  the  left  side  there  su'e  the  inputs  to 
the  system.  II,  Keyboard  Input,  represents  all  information  entered  via 
the  terminal  kejdx^rd.  This  information  might  be  data  from  the  docunent 
header,  peuameters  for  a  document  search,  or  any  other  kind  of 
information  needed  to  update  the  database  files  or  to  run  the  system 
programs.  12  represents  all  the  database  files  used  by  the  system  to 
storage  information,  either  in  a  temporary  or  permanent  basis.  Cl,  User 
Comnands,  on  the  upper  side  of  the  figure,  defines  to  the  system  what  to 
do  with  the  entered  input.  User  conmands  are  the  menu  choices,  function 
keys,  and  any  other  means  of  choosing  an  action  to  be  taken  by  the 
system.  These  actions  and  the  input  elaboraticm  produce  the  outputs, 
which  are  interpreted  on  the  right  side  as  C3?T  Displays  -  01,  Printed 
Reports  -  02,  and  Modified  Databeise  Files  -  03.  The  modified  databeise 
files  are  reused  as  input,  which  is  represented  the  diagram  by  the 
cycle  from  the  output  to  the  input. 

The  Main  Modules.  Figure  6  shows  the  AO  level  SADT  diagram 
corresponding  to  the  environment  diagram  of  Figure  5.  Although 
meaningful,  the  logical  databases  in  vhich  the  system  is  divided  are  very 
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Figure  5.  SADT  Environment  Level  Diagt'am. 

ample.  Each  one  embraces  several  attributes  that  are  not  available  at 
the  same  time.  We  need  modular  partitions  that  depict  the  available 
operations  for  the  object  docunent.  Tbese  operations  will  add  and  modify 
attribute  values  in  each  relational  databeise.  Tbey  are  grouped  in  the 
four  main  modules  shown  in  Figure  6  as  follows: 

1 .  Register  Docunent 

2.  Update  Database 

3.  Consult  Database 

4.  Maintain  'Ibesaurus 

Although  modularity  has  been  accepted  as  aui  important  software  attribute 
and  an  extension  of  the  "divide  and  conquer"  method,  we  must  strive  for  a 
few  design  heuristics.  At  this  level,  these  heuristics  are  maiximum 
cohesion  and  minimun  coupling  between  modules  to  improve  modular 
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Figure  6.  SADT  AO  Level  Diagram. 


independence  and  clarity  of  design.  The  variety  of  operations 
encompassed  by  the  system  constrain  our  first  level  decomposition  (AO)  to 
a  logic  and  temporal  cohesion,  which  will  permit  later,  the  desired 
functicmal  cohesion.  On  the  other  hand,  they  present  the  desired  loose 
coupling,  with  no  direct  coupling  between  modules. 

Register  Document.  Figure  7  shows  the  decomposition  of  the 
Register  Docunent  module.  Note  that  this  module  is  nunbered  1  in 
Figure  6,  and  that  its  decomposition,  Figure  7,  is  named  A1  on  the  left 
bottom  comer.  This  is  the  guiding  line  to  relate  a  parent  module  to  its 
decomposition.  The  document  processing  routine  begins  with  entering  data 
about  Just  received  documents.  This  data  is  extracted  from  the  docunent 
header.  The  system  gives  to  each  docunent  an  unique  Docunent  Reference 
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Figure  7,  Register  DcxjiJnent  Diagram. 


Number  -  DRN.  The  Document  Reference  Number  that  comes  from  module  All, 
Enter  Document  Data,  to  module  A12,  Print  Processing  Sheet,  points  to  the 
last  document  entered,  as  a  reminder  to  the  user  when  printing  the 
processing  sheet  -  PS.  Although  tiiese  modules  are  independent  of  each 
other,  the  typical  sequence  is  first  entering  all  received  documents, 
then  printing  the  corresponding  processing  sheets. 

Update  Database.  Figure  8  displays  the  decomposition  of  the 
Update  Database  Module.  The  decomposition  presents  functional  and 
procedtiral  cc^esion.  Module  A21,  Generic  Update  is  intended  for  generic 
situations  where  some  erroneous  data  was  introduced  in  the  catalog 
database  and  the  correcticni  using  some  of  the  other  modules  is  not 
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Figure  8.  Update  Database  Diagram. 


possible  or  convenient.  Thus,  this  module  is  mainly  related  to  the 
Protocol  or  Archive  Sections.  The  Module  A22,  Specific  Updates, 
encompeisses  several  upxiate  operations,  which  are  described  in  the 
following  section. 

Specific  Updates.  This  module  is  formed  of  various  lower 

level  modules. 

Change  Validity 

Process  Dociiiient  Destruction 

Join  Doctments 

Transfer  Custody 

Update  Microfilmed  Data 

Subject  Indexing 
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Although  they  all  modify  the  control  database  they  do  so  on  distinct 

occasions  and  for  different  purposes.  Tberefore,  they  are  separated  into 

individual  units.  Ibere  is  no  SADT  Diagram  describing  these  modules  but 

they  are  shown  in  Figure  11,  as  peu't  of  the  system  structure . 

Change  Validity  is  used  by  the  Archive  Section  vAien  an  analyst 
requests  a  change  to  the  validity  that  was  automatically  given  to 
the  document. 

Process  Document  Destruction  removes  some  data  from  the  files  (as 
document  history,  for  instance),  smd  references  the  destruction 
authorization  document. 

Join  Documents  relates  a  document  (main  docunent)  to  other  ones 
(secondary  documents)  vrfien  these  documents  are  joined  to  constitute 
a  single  doctment.  This  update  is  to  be  made  by  a  department  or  by 
the  Archive  Section.  TTiis  module  also  separates  Docvments,  giving 
them  again  their  own  individuality. 

The  Transfer  Custody  module  updates  the  document  history.  Each 
document  transference  is  made  based  on  the  Document  Transference 
Receipt  (see  Figure  Figure  23),  that  constitutes  the  sender's 
transference  proof.  The  details  of  this  receipt  are  introduced  in 
the  implementation  chapter. 

L^pdate  Microfilm  Data  adds  to  the  databeise  information  about 
microfilmed  documents. 

The  Subject  Indexing  module  creates  and  modifies  relationships 
among  documents  and  thesaurus  terms. 

Consult  Database.  Figure  9  shows  the  Consult  Database 
Mode.  Tbe  module  A31,  Browse  Database,  permits  an  overview  of  several 
documents  at  the  same  time.  It  is  further  decomposed  into  three  modules. 
Browse  by  Holder,  Browse  by  Header,  and  Browse  by  Subject.  TTiey  are 
specially  useful  vdien  the  searcher  is  not  sure  about  the  document  he  is 
looking  for  or  the  adequate  keys  to  use  in  a  query.  The  module  Browse  by 
Holder  permits  a  Department  to  control  its  own  document  processing.  As 
was  stated  before,  the  name  of  the  peraon  who  is  actuBLlly  analyzing  a 
document  is  not  compulsory  information.  Although  from  a  centralized 
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Figure  9.  Consult  Database  Diagraa. 

viewpoint  is  enough  to  know  the  Department  responsible  for  a  document, 
these  modules  can  and  should  be  freely  used  by  a  Department  as  its 


internal  control  over  the  documents  that  are  being  processed  and  to 
identify  the  person  who  is  processing  each  one  of  them. 

Look  Up  Thesaurus  Terms  is  a  feature  to  search  for  a  thesaurus  term 
that  approximates  some  desired  concept.  It  permits  the  user  to  navigate 
through  the  thesaurus  tree. 

The  Retrieve  Documents  module  permits  a  document  search  by  any 
document  attribute  and  gives  a  complete  information  about  the  documents 
retrieved.  The  result  of  a  query  is  a  list  of  the  documents  that  satisfy 
the  request.  These  documents  may  be  seen  one  at  a  time  on  the  screen. 
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Maintain  Thesaurus.  Figure  10  shows  the  decoaposition  of  the 
Maintain  Thesaurus  Module.  Observe  that  the  thesaurus  aaintenance  is 
quite  independent  of  the  other  aain  aodules.  As  a  standard  systea  used 
by  various  organizations,  we  are  interested  in  keeping  identical 
thesaurus  teras.  This  is  easier  accoaplished  by  having  an  unified 
thesaurus  aaintenance.  For  this  reason  only  the  organization  responsible 
for  the  thesaurus  aaintenance  needs  the  coaplete  Thesaurus  Maintenance 
Module.  This  organization  would  concentrate  the  requests  for  changes  and 
distribute  upgraded  versions  of  the  thesaurus  teras. 


Figure  10.  Maintain  Thesaurus  Diagraa. 
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Tlie  System  Structure 

■nie  system  structure  chosen,  presented  in  Figure  11,  closely 
resembles  the  decomposition  already  made.  The  necessity  for  defining  the 
interfaces  between  modules  is  attenuated  by  using  a  Database  Management 
System  (DBI^),  vdiich  consists  of  a  collection  of  interrelated  data  and 
programs  to  access  that  data.  Database  systems  are  designed  to  manage 
l8a*ge  bodies  of  information.  Therefore,  they  already  provide  a  storage 
structure  and  mechanism  for  the  manipulation  of  information,  including 
provisions  for  the  safety  of  the  information  stored.  On  the  other  hand 
the  data  structures  become  more  important.  The  data  structures  are 
expressed  as  the  database  model  that  permits  the  DBMS  to  euxsess  the 
necessary  information  in  the  files.  The  database  model  presented  in  the 
next  chapter. 

To  present  the  complete  structure  of  the  system  we  have  anticipated 
the  modules  that  constitute  the  thesaurus  maintenance,  although  reserving 
for  the  next  chapter  the  explanations  about  the  thesaurus  theory. 
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III.  Theory 


Thesaurus 

The  thesaurus  is  the  heart  of  the  subject  database.  To  better 
understand  the  distinct  roles  that  the  subject  databeise  and  the  catalog 
database  play  we  may  divide  the  relevant  information  for  retrieving 
documents  from  the  collection  into  two  units: 

1.  A  set  of  data  which  defines  a  specific  dociment,  that  is,  the 
document  identification  or  physical  description. 

2.  A  subjective  set  of  terms  which  describes  the  dociment  contents, 
that  is,  the  information  the  docunent  transmits. 

The  first  one  involves  a  process  called  cataloging  and  the  second  one 

subject  indexing.  The  subject  indexing  process  has  two  steps: 

-  the  conceptual  analysis  of  a  document. 

-  the  translation  of  the  conceptual  analysis  into  a  particular 
vocabulary. 

The  translation  of  the  conceptual  analysis  into  a  particuleu:  vocabulary 
employs  a  controlled  vocabulary,  that  is,  a  limited  set  of  terms  used  by 
both  the  indexer  and  the  searcher  to  represent  the  docunent  contents. 

The  vocabulary  might  vary  from  a  sinqple  list  of  subject  headings, 
keywords  or  phrases,  to  a  thesaurus.  The  proposed  system  uses  a 
Thesaurus  that  is  the  most  lised  approach  in  information  retrieval 
applications  (Jackson,  1971:1).  In  the  thesaurus  approach,  a  docunent  is 
regarded  as  a  list  of  terms.  A  decision  to  retrieve  or  not  retrieve  is 
made  by  determining  idiether  the  list  of  terms  which  represents  the 
document  matches  the  terms  of  the  request.  The  vhole  vocabulary  is 
logically  subdivided  into  individual  vocabulEU'ies  or  subsets,  each  one 
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pertaining  to  different  subject  areas  called  Classes,  the  vocabulary  is 

structured  to  show  relationships  between  terms.  Strict  rules  are 

established  to  define  permissible  structuring,  the  relationship  between 

two  terms  may  be  expressed  by  a  three  element  tuple  where  the  first 

element  is  the  main  term  -  MAINTR,  the  third  element  is  the  secondary 

term  -  SECTO,  emd  the  second  element  is  the  two-letter  code  -  REL,  which 

expresses  the  relationship  that  relates  the  main  term  to  the  secondary 

term.  The  relationships  implemented  in  the  subject  database  are: 

Hierarchical  Relationship. 

.  Broader  Term  (BT) 

.  Iferrower  Term  (NT) 

The  hierarchical  relationship  is  represented  by  the  codes  BT  and 

NT.  The  first  one  means  broader  term  and  the  second  one  narrower  term. 

As  an  example)  the  hierarchical  relaticmships  that  are  depicted 

on  Figure  12  would  be  expressed  as: 

<POLICY  , NT, POLITICAL  DOCrRINES> 

<POLICY  , NT, EXTERNAL  PCa.ICY  > 

<POLICy  , NT, INTERNAL  POLICY  > 

<POLICY  , NT, SECTORAL  POLICY  > 

<INTERNAL  POLICY, NT, FEDERAL  POLICY  > 

<INTERNAL  POLICY, NT, STATE  POLICY  > 

<SECrCHAL  POLICY, NT, AGRICULTURAL  POLICY> 

<SECTCRAL  POLICY, NT, TRANSPCRT  PIXICY  > 

<SECTCRAL  POLICY, NT, ENERCfY  POLICY  > 

Those  tuples  only  describe  half  of  the  hierarchical  relationships  that 

are  depicted  on  Figure  12.  Two  rows  are  necessary  to  completely  express 

each  single  hierarchical  relationship  between  two  terms,  that  is,  we  have 

to  create  reciprocal  entries.  The  reciprocal  is  obtained  by  switching 

the  main  and  secondary  term  and  replacing  the  relationship  code  by  its 

inverse,  that  is,  NT  by  BT  (or  BT  by  NT). 

<POLITICAL  DOCTRINES, BT, POLICY  > 
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Figure  12.  Hierarchical  Relationship. 

<EXTERNAL  POLICY  ,BT, POLICY  > 

< INTERNAL  POLICY  ,BT, POLICY  > 

<SECnX»AL  POLICY  ,BT, POLICY  > 

<FEDERAL  POLICY  ,BT, INTERNAL  POLICY> 

<STATE  POLICY  ,BT, INTERNAL  PaLICY> 

<A£2?ICUL'I\JRAL  POLICY, BT.SECTCKAL  POLICY> 

<TRANSP«?T  POLICY  ,BT, SECTORAL  PC4.ICY> 

<ENERGY  POLICY  ,BT, SECTORAL  POLICY> 

When  retrieving  docunents,  the  replacement  of  a  term  by  a  broader  term 

has  the  effect  of  increasing  the  number  of  docunents  retrieved.  In  the 

other  hand,  we  might  retrieve  documents  which  are  not  relevant,  the 

replacement  of  a  term  by  a  narrower  term  has  the  reverse  effect.  A  term 

cannot  have  more  than  one  broader  term  relationship. 
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Aascxiiative  Relationship. 

.  Related  Term  (RT) 

The  associative  relationship  is  represented  by  the  code  RT  which 
means  related  term.  It  is  used  to  approximate  similar  terms,  vAiich  are 
alphabetically  or  hierarchically  sepeurated,  and  related  terms,  vdiich  are 
frequently  associated  during  retrieval  operations.  The  necessity  of 
using  such  relationship  may  arise  from  relating: 

-  a  thing  and  its  application 

-  an  effect  and  a  cause 

-  a  thing  and  property  strongly  associated  with  it 

-  a  raw  material  and  a  product 

-  two  complementary  activities 

-  an  activity  eind  an  agent  of  that  a^jtivity 

-  an  activity  an  a  product  of  that  activity 

-  a  thing  and  its  parts 
[Lancaster,  1986:46-47] 

A  simple  example  of  this  kind  of  relation  is  the  association  of  computers 

with  keyboauxis  amd  printers.  Since  the  hierarchical  relationship  would 

be  ambiguous,  this  relationship  is  expressed  as: 

<OOMEVrERS ,  RT ,  KEYBOARDS  > 

<CXDMEVrERS,RT, PRINTERS  > 

<KEYBOARDS ,  RT ,  OOMPITTERS  > 

<PRINTERS  ,RT, COMPUTERS > 

Note  that  the  associative  relationship  also  requires  reciprocal  entries. 

The  reciprocal  is  obtained  by  switching  the  main  term  and  8econdau7  term 

of  the  original  tuple. 

Synonymy  Relationship. 

.Use  (US) 

.Used  For  (UF) 

The  synonymy  relationship  is  represented  by  the  codes  US  an  UF. 

The  first  one  means  "use"  amd  the  second  one  means  "used  for."  This 
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relationship  assigns  a  single  term  to  represent  each  unique  concept. 

Other  terms  considered  to  be  synonymous  or  neeur-synonymous  indicate  the 

elected  term.  In  turn,  the  single  term  indicates  the  other  terms  it 

represents.  The  following  entries  would  represent  a  synonymy  relationship 

among  priest,  pastor,  reverend,  rabbi,  and  clergyman; 

<PRIEST  ,UF,PASTC»  > 

<FRIEST  ,UF, REVEREND  > 

<FRIEST  ,UF, RABBI  > 

<PRIEST  ,UF,CLERC!YMAN> 

<PASTC»  ,  US,  PRIEST  > 

<REVEREND  , US, PRIEST  > 

<RABBI  , US, PRIEST  > 

<CIJERGYMAN,US,raiEST  > 

A  term  that  has  a  "use"  relationship  cannot  have  any  other  relationship. 
Since  we  are  indicating  another  term  to  the  user,  all  further 
relationships  should  be  applied  to  the  indicated  term. 

The  relationships  between  terms  are  the  thesaurus  essence,  but 
other  attributes  are  also  necessary  to  inqplement  the  vocabulary.  The 
following  paragraphs  formally  identify  all  attributes  for  the  Subject 
Database. 

Term  Description  -  TERM.  The  term  description  expresses  the 
desired  concept  and  might  be  formed  by  one  or  more  words.  Each  Term 
Description  must  be  unique.  Suppose  we  have  a  class  named  cities  and 
another  claiss  named  states.  If  we  have  a  city  and  a  state  with  the  same 
name  we  differentiate  them  by  adding  its  class  (between  parentheses)  Just 
after  the  word.  For  instance,  suppose  that  cities  pertain  to  cleiss  05  and 
states  pertain  to  cleiss  06.  To  enter  SAO  PAULO  city  and  SAO  PAULO  state 
we  would  enter  these  terms  as:  SAO  PAU10(05)  and  SAO  PAULO(06). 
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Class  r  CLASS .  A  class  logically  subdivides  the  whole  vocabulary 


into  individual  vocabularies  or  subsets,  each  one  pertaining  to  a 

different  subject  area.  A  docusent  nay  be  indexed  under  terss  pertaining 

to  a  various  classes.  The  searcher  is  able  to  retrieve  a  docusent  not 

only  by  the  precise  ters  but  also  by  the  cosbination  of  terss  pertaining 

to  distinct  classes.  Moreover,  the  searcher  is  able  to  select  all 

docusents  that  we  indexed  by  terms  hierarchically  subordinated  to  a 

chosen  ters.  A  class  nase  is  also  a  ters  in  the  thesaurus  and  all  terss 

that  have  hierarchical  relationships  are  descendants  of  their  classes. 

Classes  are  intended  for  two  sain  purposes: 

to  facilitate  the  choice  of  terss.  Dividing  the  all  vocabulary 
into  logically  related  smaller  sets  gives  the  searcher  an  intuitive 
notion  of  where  to  look  for  a  desired  term; 

-  to  permit  the  system  to  use  a  set  of  terms  as  consistency 

constraints.  For  instance,  organization  names  sight  be  a  class 
used  to  verify  the  database  entries  for  document  senders. 

Class  Code  -  CLASSCD.  The  class  code  was  created  to  reduce  disk 

space  needs.  As  the  class  is  repeatedly  used,  the  internal  use  of  such  a 

code  to  represent  the  class  avoids  wasted  space. 

Main  Term-MAINTR.  A  main  term  is  a  thesaurus  term  that  constitutes 

the  domain  term  of  a  relationship  between  terms. 

Secondary  Term  -  SECTR.  A  secondary  term  is  a  thesaurus  term  that 

constitutes  the  codomain  of  a  relationship  between  terms. 

Relationship  Between  terms  -  REL.  The  relationship  between  terms 

is  a  two-letter  code  that  represents  the  relation  between  two  terms  in 

the  thesaurus. 

BT  Broader  Term 
NT  Narrower  Term 
RT  Related  Term 


39 


US  Use 

UF  Used  For 

Scope  Notes  -  NOTE.  Scope  notes  are  used  to  define  or  cleurify 
ambitfuoias  terms,  to  provide  complete  spelling  of  truncated  terms,  or  to 
provide  historical  data  on  changes  in  usage  for  a  given  term.  It  is  a 
guide  to  how  a  particular  term  should  or  should  not  be  used.  For 
instance,  suppose  we  have  the  term  "CXJMGAR''  that  pertains  to  the  class 
"Organization" .  Its  Scope  Note  can  be  the  complete  name  of  the 
organization:  "Comando  Geral  do  Ar." 

Figure  13  illustrates  possible  relationships  of  a  main  term.  Note 
that  a  terra  may  have  at  most  one  broader  term,  vAiile  having  several 


Figure  13.  Main  Term  and  Possible  Relationships. 
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narixwer  terms.  'Die  same  term  cannot  have  "use"  and  "used  for" 


relationships  simultaneously.  A  term  that  has  a  "use"  relationship 
cannot  have  any  other  relationship. 

Databeise 

In  the  following  sections  we  explain  some  fundamental  concepts  about 
data  models,  data  manipulation  languages,  Euid  database  management  systems 
used  in  constructing  the  proposed  system. 

The  Entity-Relationship  Data  Model.  Tbe  Entity-Relationship  Data 
Model  (E-R)  has  been  used  for  performing  logical  database  design  for 
relational  systems.  It  is  used  in  describing  data  at  the  conceptual 
level  because  it  is  semantically  rich.  The  E-R  model  perceives  the  world 
ais  entities  and  relationships.  The  model  provides  for  a  high  degree  of 
data  independence  and  is  based  on  set  and  relaticm  theories.  Tbe  logical 
structure  of  the  entity-relationship  data  model  is  graphically  expressed 
as  follows: 

Rectangles .  Represent  entity  sets.  An  entity  is  an  object 
that  exists  and  is  distinguishable  from  other  objects.  A  double  line 
rectangle  represents  a  weak  entity.  A  weak  entity  does  not  have  a 
candidate  key  and  its  existence  depends  c»)  the  existence  of  a  regular 
entity. 

Ellipses.  Indicate  attributes  of  an  entity.  An  entity  may 
be  represented  by  a  set  of  attributes.  A  star  inside  a  ellipse  denotes  a 
candidate  key  for  the  set  of  attributes. 

Diamonds.  Denote  relationships  among  entity  sets. 


Lines .  Link  attributes  to  entity  sets  and  entity  sets  to 
relationships  (Korth  and  Silberschatz,  1986:6-7). 

Data  Independence .  There  are  two  levels  of  data  independence,  the 
physical  and  the  logical  levels.  This  means  that  the  programs  to  access 
the  database  do  not  have  to  be  rewritten  after  a  physical  or  logical 
modification  on  the  database.  A  physical  modification  is  a  change  in  how 
the  data  are  stored.  A  logical  modification  is  a  change  in  vhat  data  are 
actually  stored  in  the  database  and  the  relationship  that  exist  among 
data. 

Data  Integrity.  This  means  that  the  data  in  the  database 
have  to  satisfy  some  integrity  constraints  that  8u?e  specified  explicitly 
by  the  databeise  administrator.  As  an  example,  suppose  the  constraint  of 
a  term  name  which  has  to  be  unique.  It  should  be  impossible  to  enter  a 
new  term  with  the  seune  name  as  an  existing  term.  A  particulau'  case  of 
data  integrity  tdiich  the  DBMS  must  ensure  is  known  as  "data  consistency". 
It  consists  of  keeping  contradictory  information  from  the  databetse.  An 
example  is  a  same  term  with  "use"  and  "used  for"  relationships 
simultaneously. 

Security  Enforcement.  The  data  stored  in  the  database  needs 
to  be  protected  from  unauthorized  access,  intentional  destruction,  and 
malicious  alteration.  While  "integrity"  refers  to  accidental  loss  of 
consistency,  security  usually  is  related  to  protection  against 
deliberated  misuse.  A  DBMS  usually  provides  security  by  using  peisswords 
vhich  authorizes  the  access  to  only  portions  of  the  database  and  to 
perform  limited  operations. 
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Backup  and  Recovery.  A  computer  failure  due  to  mechanical  or 
electrical  problems  may  result  in  data  loss.  The  DBMS  has  to  offer  means 
to  detect  such  occurrences  and  to  restore  the  database  to  a  state  that 
existed  prior  to  the  failure. 

Concurrence  Control .  When  several  users  may  update  the 
database  at  the  same  time  there  is  a  threat  of  data  inconsistency.  The 
DBMS  has  to  control  these  interactions  in  a  such  a  way  that  no  heirm  can 
result  from  these  operations. 

Data  Mainipulation  Language  ^  DML.  Comnands  are  entered  by  the  user 
and  processed  by  the  database  management  system.  These  commands,  also 
called  statements,  and  the  rules  that  constraint  their  uise  constitutes 
the  data  manipulation  language.  Every  DBMS  possesses  its  own  database 
language.  Ali^hough  there  are  differences  among  database  languages  they 
are  divided  into  two  basic  groups:  "procedural"  and  "nonprocedural."  A 
procedural  DML  requires  the  user  to  specify  which  data  is  needed  and  how 
to  get  it,  that  is,  the  user  provides  the  sequence  of  operations  that 
generates  the  desired  answer.  A  nonprocedural  DML  just  requires  an  user 
to  specify  vhat  data  is  needed. 

A  relational  DBMS  manipulates  the  data  according  the  concepts  and 
ideas  of  that  relational  data  model  described  earlier  (see  page  41). 

They  use  manipulation  (query)  languages  generically  known  as  "relational 
database  languages",  which  are  classified  as  nonprocedural  languages. 

SQL,  Structured  Query  Langueige,  is  one  of  the  best  known  relational 
database  languages.  SQL  can  be  used  in  two  modes:  interactive,  emd 
embedded.  In  interactive  SQL,  statements  are  entered  at  a  terminal  or 
microcomputer  and  immediately  processed  or  interpreted.  In  the  embedded 
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SQL,  statements  are  embedded  in  a  program  written  in  another  language 
(procedural).  Tbese  statements  are  not  imnediately  executed.  They  aire 
processed  only  vAien  the  host  program  is  run. 

The  basic  SQL  expression  consists  of  three  clauses:  select,  from, 
and  vAiere.  Tbe  "select"  clause  lists  the  desired  attributes  or  colvmns 
of  a  table.  The  "from"  claixse  lists  the  relations  or  tables  that  will  be 
scanned  in  the  execution  of  the  expression.  Finally,  the  "vdiere"  clause 
establishes  certain  conditions  involving  attributes  that  have  to  be  met. 

(^^CLE  Relational  Database  Managanent  System.  The  Oracle  RDBMS  was 
the  database  management  system  chosen  to  implement  the  proposed  system. 

It  is  a  relational  database  designed  to  run  on  a  microcomputer  equivalent 
to  the  IBM  PC/AT,  vrtiich  may  be  attached  to  a  computer  network.  The 
system  is  compatible  with  S/  and  DB2,  which  are  IBM  database  systems  that 
run  on  large  IBM  computers.  According  the  Oracle  manual  (Oracle,  1987:3) 
Oracle  runs  on  many  different  mainframe  computers,  miniconiputers  and 
microcomputers,  being  available  on  over  30  operating  stems  and  80 
hardware  platforms.  Its  Query  language,  SQL^Plus,  offers  a  rich 
collection  of  features.  The  system  offers  in  addition  SQL*Foniis,  an 
application  development  tool  also  integrated  to  the  system  that  piermits  a 
quick  development  of  forms-baised  applicaticsis  for  entering,  querying, 
updating  and  deleting  data.  Forms  aure  specified  using  memos  and  a  screen 
painter.  Instructions  and  embedded  SQL  statements  are  combined  to 
generate  the  application.  More  explanations  about  the  system  will  be 
given  in  the  chapter  describing  the  implementation. 


44 


rv.  Data  Base  Design 

Introduction 

According  the  "Webster's  New  Word  Dictionary"  (Simon  and  Schuster, 

1984:360),  the  definition  of  database  is  as  follows: 

"A  large  collection  of  data  in  a  computer  organized  so  that 
it  can  be  expanded,  updated,  aind  retrieved  rapidly  for 
various  uses. 

This  collection  of  data  has  to  be  organized  in  some  way.  Moreover,  we 
need  a  set  of  programs  to  manage  the  data  files  in  order  to  expand,  to 
update,  and  to  retrieve  information.  We  used  the  Entity-Relationship 
data  model  for  performing  the  logical  database  design.  Tbe  E-R  model  was 
introduced  by  Peter  Chen  in  1976.  Most  of  the  concepts  presented  in  this 
section  are  borrowed  from  him  (Chen,  1976). 

The  logical  view  of  data  is  an  important  issue.  The  E-R  model 
describes  the  world  in  a  natural  emd  intuitive  way  that  consists  of 
entities  and  relationships.  In  this  work  the  E-R  model  is  used  at  two 
levels:  first,  to  convey  information  concerning  entities  and 
relationships  vAiich  exist  in  the  designer  mind;  second,  to  provide 
information  structure,  the  organization  of  data  where  the  entities  and 
the  relationships  are  substituted  by  values. 

Information  Concerning  Entities  and  Relationships 

An  entity  is  an  object  that  can  be  distinctly  identified.  Some 
people  may  view  a  certain  object  as  an  entity,  while  other  persons  may 
view  it  SIS  a  relationship.  Entities  sure  classified  into  different 
"entity  sets".  There  are  predicates  sissociated  with  each  entity  set  that 
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identifies  an  instantiation  of  an  entity  as  belonging  to  that  set.  If  we 
know  that  an  entity  is  in  a  certain  set,  then  we  know  that  it  has  the 
properties  conmon  to  the  other  entities  that  pertain  to  the  same  set. 

A  relationship  is  an  association  between  entities.  The  "role"  of 
an  entity  in  a  relationship  is  the  function  that  it  performs  in  the 
relationship.  A  "relationship  set"  is  a  mathematical  relation  among  a 
number  of  entities,  each  of  them  taken  from  em  entity  set. 

Table  IV  shows  the  most  important  entities  and  relationships  that 
exist  on  the  proposed  system. 

Information  Structure 

The  information  about  an  entity  or  a  relationship  may  be  recorded 
as  pairs  of  <at tribute, data  value>,  idiere  attribute  is  a  predicate  name. 
If  an  entity  has  5  attributes,  for  instance,  thus  we  can  describe  an 
entity  instantiation  by  5  pairs  of  attribute-data  value.  Note  that 
relationships  also  have  attributes. 

Primary  Keys.  The  values  of  an  attribute  can  be  used  to  uniquely 
identify  an  entity  in  an  entity  set.  Ihe  attribute  used  for  this  task  is 


Table  TV.  Major  Entities  and  Relationships. 


Entities 

Relationships 

Document 

Document/Ref erence 

Reference 

Docimient/Annex 

Annex 

Document /Microf  i  Im 

Microfilm 

Join  (Document-Docunent) 

Thes.  Term 

Document  Log(Doc/Datetime/Depart. ) 

Department 

Holder  (Doc/HolderDepeurt./Holdeitlame) 

Holder 

Subject  Index  (Document /Term) 

Relationship 

Rel.  Between  Terms  (Term/Relat./Term) 
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known  as  "prinaary  key".  If  there  is  no  attribute  with  unique  values  we 
can  use  two  or  more  attributes.  If  even  using  all  attributes  available 
in  the  entity  set  it  is  still  iu^ssible  to  uniquely  identify  each 
entity,  or  if  simplicity  in  identifying  entities  is  desired,  we  can 
define  a  new  attribute  so  that  such  identification  becomes  possible. 

Document  Entity  Set.  Figure  14  shows  the  DOCUMENT  entity  set. 

Note  that  Document  Reference  Nimiber  (CRN)  is  an  attribute  created  to 
sinqplify  document  identification.  Protocol  Nunber  (PBOT)  could  have  been 
elected  the  primary  key.  It  was  not  chosen  for  convenience.  The 
protocol  number  is  Isu^e,  difficult  to  memorize,  and  does  not  denote  the 
physical  place  vdiere  the  document  is  kept.  On  the  other  hand  a  WiN 
indicates  the  document  registering  year,  the  document  origin  (received  or 
sent  code ) ,  and  the  chronological  sequence  number  ( of  receiving  or 
sending).  The  DRN  maps  the  exact  archive  vAiere  the  document  is  filed. 

The  Efts  "89  1  345",  for  instance,  denotes  the  345th  document  received  in 
1989. 

When  an  entity  cannot  be  uniquely  identified  by  the  values  of  its 
own  attributes  we  must  use  e.  relaticxuship  to  identify  it.  Ihis  is  known 
as  a  "weak  entity  relationship".  The  concept  of  weak  entity  is  also 
related  to  the  concept  of  "existence  dependency"  (Koiiii  and  Silberschatz, 
1986:29).  In  Figure  14  the  entity  set  Reference  is  depicted  as  a  weak 
entity.  If  we  think  that  its  single  attribute,  REFER,  is  a  document 
reference  number  (IXZN)  we  may  conclude  that  it  unic^ly  identifies  a 
reference.  Iherefore,  it  would  not  be  a  weak  entity.  REFER,  would  be 
the  «itity  set  primary  key.  The  problem  is  that  the  reference  by  itself 
does  not  make  sense.  We  are  interested  in  the  relaticxiship  between  a 
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Figure  14.  Document  Entity  Set. 

docunent  and  a  reference.  There  is  no  utility  in  knowing  the  reference 
without  knowing  the  docimient  that  references  it.  Furthermore,  REFER  is  a 
free  description  of  a  reference  which  may  consist  of  a  Document  Reference 
Ntmber,  the  name  of  a  book,  or  anything  else;  therefore,  it  might  have 
homograph  references  with  distinct  meanings.  For  all  these  reasons  the 
existence  of  the  Reference  entity  depends  cwi  the  Docunient  entity. 
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Moreover,  there  is  no  necessity  for  iapleaenting  both  the  relation 


corresponding  to  the  Reference  entity  set  and  the  relation  corresponding 
to  the  DOC/REFER  relationship  set.  We  shall  see  later  (see  page  54)  that 
relationship  sets  derived  from  the  association  of  a  weak  entity  with  a 
strong  entity  contain  the  sase  attributes  as  those  of  the  weak  entity. 

For  sinilar  reasons,  the  entity  set  Annex  is  also  presented  as  a  weak 
entity. 

Join  Relationship.  The  Join  relationship  is  illustrated  in 
Figure  15.  The  relationship  set  coaponents  are  both  Docuaent  Reference 
Nuabers.  Their  naaes,  MAIN  and  JOINED,  reflect  the  "role"  they  perfora. 
The  arrow  on  the  MAIN  side  aeans  there  is  a  l:n  (n=0,  1,  2,  ...)  aapping 
froa  MAINDOC  to  JOINED,  that  is,  each  aain  docuaent  aay  have  none,  one. 


or  more  Joined  docunents.  When  no  arrow  exists  on  both  sides  of  a 
relationship  the  mapping  is  n:m  (n=0,  1,  2,  and  m=0,  1  ,  2,  ...)• 

Microfilm  Relationship .  Figure  16  illustrates  the  Microfilm 
relationship  set  and  the  Microfilm  entity  set.  The  diagram  indicates 
that  each  docunent  may  have  none,  one,  or  more  microfilm  entities.  Each 
microfilm  entity  is  a  frame  sequence  expressed  by  the  type  of  microfilm, 
its  number,  and  initial  and  final  frame  number.  Although  the  microfilm 
entity  set  possesses  a  primary  key  formed  by  taking  the  attributes 
F_TYPE,  F_NO,  and  FIRST  (or  FINAL)  together,  it  is  expressed  as  a  weak 
entity  to  indicate  existence  dependency  on  the  Dociment  entity  set.  When 
a  document  is  eliminated  from  the  Docunent  entity  set,  we  also  eliminate 
the  relationships  on  the  Microfilm  Indexing  relationship  set  that 
correspond  to  the  docimient  being  excluded.  Although  we  do  not  physically 
destroy  the  microfilm,  we  lose  the  pointers  to  the  frames. 


Dcx^unent  and  Departjnent  Relationships .  Figure  17  illustrates  the 
association  of  the  Depeu'tment  entity  set  to  the  Docunent  entity  set. 
These  entity  sets  define  two  relationship  sets:  Docunent  Log  and  Holder. 
On  the  Docunent  Log  relationship  set  the  Datetime  attribute  guarantees 
the  uniqueness  of  each  relationship  and  provides  means  to  serialize  the 


Figure  17.  Docunent  History  and  Department. 


docunent  processing.  For  a  given  docunent  at  each  datetime  there  is  only 
one  sending  department  and  only  one  receiving  department.  In  fact,  we 
shall  see  later  that  the  primniry  key  of  the  Docunent  Log  relationship  is 
composed  only  of  the  MiN,  the  sender  department  and  the  transference 
date.  The  situation  vhere  a  same  department  sends  the  same  document  more 
than  once  a  day  is  so  rare  that  it  is  considered  an  error.  The  time 
attribute  has  an  inqportant  role  in  ordering  transferences  that  were  made 
in  the  same  day.  Some  constraints  cannot  be  described  symbolically. 
Docunent  transference  is  made  by  means  of  a  receipt.  It  is  possible  that 
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transferences  are  entered  in  the  system  out  of  order.  In  this  situation 
we  have  a  temporary  anomaly.  The  docunent  log  may  indicate  that  someone 
hats  sent  a  document  vAiich  was  not  previously  received.  We  want  to  be 
able  to  recognize  this  inconsistency  and  to  recover  when  the  missing 
record  is  entered. 

The  second  relationship  set,  Holder,  permits  the  identification  of 
a  department  code  and  a  holder  person  name  vAiich  aire  responsible  for  a 
document.  The  diagram  shows  that  the  name  of  the  holder  is  not  directly 
related  to  the  depeirtment  set.  It  was  designed  to  permit  a  department  to 
keep  its  own  control  over  the  personnel  su^tually  processing  documents 
without  bringing  unnecessary  complexity  to  the  system  (see  Docunent 
History,  page  20).  Therefore,  there  is  neither  the  necessity  of  entering 
this  information  on  the  system  (it  is  optional)  nor  prior  registering  the 
name  that  is  going  to  be  entered. 

Docmient-Thesaurus  Relat ionships ♦  Figure  18  shows  the  entities  and 
relationships  related  to  the  thesaurus  The  single  attribute  of  a 
thesaurus  term  is  its  class.  The  primary  key  of  the  term  entity  set  is 
the  term  name.  The  class  logically  divides  the  terms  in  related 
subjects.  A  claiss  entity  set,  not  shown  in  the  illustration,  is  used  for 
data  validation  purposes.  It  was  decided  to  use  the  term  name  as  the 
primary  key,  instead  of  the  term  name  and  the  cle^s.  As  a  consequence, 
the  term  name  must  be  unique.  It  was  chosen  for  the  sake  of  simplicity. 
The  occurrence  of  duplicated  terms  does  not  justify  having  to  specify  a 
term  class  in  adl  term  relaticxishipe  and  queries.  As  we  do  not  expect  a 
large  number  of  duplicates,  the  simplest  solution  is  to  add  the  class 
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code  to  the  name  itself,  to  differentiate  from  an  existing  homographic 
term. 


Figure  18.  Ihesaurus-Document  Entities  and  Relationships. 


The  first  step  in  defining  a  new  term  is  entering  the  term 
description  on  the  Terms  entity  set.  We  may  supply  the  user  with  usage 
details  by  creating  a  scope  note  associated  to  the  entered  term.  Ihe 
next  step  is  defining  relationships  between  the  new  term  and  other 
existing  terms.  Different  consistency  constraints  apply  for  eeich 
relationship  between  terms  (REL).  These  constraints  are  shown  in 
Appendix  C,  page  121. 

Reducing  E-R  PiMrams  to  Tables .  The  E-R  diagrams  can  be 
represented  by  a  collection  of  tables.  Table  V  shows  the  tables  derived 
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Table  V.  Tables  Derived  from  the  E-R  Diagrams. 


DOCUMENT  (I«N.  P_SC,  P_OC,  P_NIWBER,  P_YEAR,  IIWR,  IDOOMPL, 
C*(»IAME,  ISSUEDT,  TITLE,  DCX:rrYPE,  CLASSIF,  VALIDITY, 
JOINSTS,  PROCSTS,  FOWSTS,  HISTSTS,  ABCWSTS) 

REFERENCE  (DRN,  REFER) 

ANNEX  (HIN,  ANNEX) 

JOIN  (MAIN,  JOINED) 

MICROFILM  (^,  F  TYPE.  F  NO.  FIRST.  LAST) 

DEPARIMENT  (DEPOODE) 

HOLDER  (ERN,  DEPOODE,  NAME) 

DOC_LOG  (DRN,  DATE.  TIME,  SEND  PEP.  REC_DEP) 

TERMS  (TERM.  CLASSCD) 

CLASSES  (CLASSCD.  CLASS) 

RELSHIPS  (MAINTR,  REL,  SECOOD) 

NOTES  (TERM,  NOTE) 

SUBJECT  (E«N,  TERM) 


from  the  previous  diagrams.  As  a  general  rule,  for  each  entity  set  and 
for  each  relationship  set  in  the  model  we  define  an  unique  table.  In 
tables  derived  from  entity  sets,  the  colunns  correspond  to  attributes  in 
the  former  entity  set.  In  tables  derived  from  relationship  sets,  the 
columns  correspond  to  those  attributes  that  COTJstitute  the  primary  keys 
of  the  originating  entity  sets.  Weak  entities  eue  an  exception  to  the 
general  rule.  The  table  derived  from  a  weak  entity  cmtains  all 
attributes  of  that  entity  plus  the  attribute(s)  that  constitutes  the 
primary  key  of  the  strong  entity  on  which  the  weak  entity  depends.  The 


Reference,  Annex,  auid  Microfilm  entities  are  examples  of  weaik  entities. 

We  observe  on  Table  V  that  those  tables  have  the  document  reference 
number  (K2N)  as  an  attribute.  In  this  case,  the  tables  derived  from  the 
relationship  set  and  from  the  entity  set  are  equal.  Therefore,  we 
implement  only  one  of  them.  The  colxmms  that  constitute  the  primary  key 
of  each  table  are  underlined.  A  table  that  has  no  underlined  colimins  has 
the  primary  key  composed  of  all  colimins. 

Figure  19  illustrates  the  tables  needed  to  compose  the  information 
about  a  document.  Note  that  a  joined  docimient  has  only  one  main  document 
while  a  main  document  may  have  several  joined  documents.  The  document  in 
the  figure  has  been  microfilmed.  Therefore,  it  must  have  the  "form 
status"  set  to  ”M"  of  microfilm.  If  it  were  a  destroyed  document  it 
would  have  only  the  document  and  reference  entries.  The  reference  would 
be  pointing  to  the  document  that  authorized  its  destruction,  while  the 
form  status  would  contain  the  value  "D"  of  destroyed  docunent.  Since  the 
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Introduction 

This  chapter  addresses  the  implementation  of  a  prototype  of  the 
proposed  system.  Tlie  term  prototype  is  used  in  a  sense  of  "a  first 
system"  that  still  1ms  to  be  evaluated  by  the  user  and  refined  to  reach 
its  final  form.  It  does  not  mean  a  "working  prototype"  from  the 
"prototyping"  software  peuradigm,  which  is  used  only  eis  a  tool  to  refine 
requirement  specifications.  A  "working  prototype"  may  even  use  a 
inappropriate  operating  system  or  progranming  languages  because  it  is 
mainly  concerned  with  a  quick  development  for  demonstrating  capabilities. 
The  prototype  developed  in  this  thesis  effort  is  not  an  adaptation  of 
program  fragments  intended  to  show  systan  potential  but  a  full 
implementation  of  all  specifications  presented  in  the  previous  chapters. 
We  present  the  steps,  how  they  were  accomplished,  the  reasons,  facilities 
and  difficulties.  First  we  talk  about  fourth-generation  languages  in 
general,  and  about  SQL  language  and  Oracle’s  Relation  Data  Beise  MEumger 
System  (RDBMS)  in  particular.  We  divided  the  implementation  into  several 
steps,  each  discussed  in  detail.  Additional  information  about  system 
files,  field  specifications,  screen  templates,  SQL  statements,  and 
triggers  are  given  in  the  appendices. 

Forth-Generat i on  Languages  ^  4GL 

Fourth-generation  languages  are  consequence  of  the  need  to  instruct 
computers  more  easily  and  more  quickly  than  in  the  past.  First 
generation  languages’  characteristic  was  the  binary  notation  (cmes  and 
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zeros),  since  eea^ly  computers  did  not  have  interpreters  or  compilers  to 
translate  machine  language  to  a  more  readable  form.  The  second 
generation  languages  used  symbolic  assembly  languages  vdiere  the  physical 
address  of  variables  and  their  names  became  independent.  Third 
generation  lainguages  have  been  used  since  1960  and  are  referred  to  as 
"high-level”  languages.  They  have  been  continually  improved  and  still 
are  extensively  used.  Some  of  their  most  important  aispects  are  the  use 
of  English  words,  mathematical  notation,  and  the  hardware  independence, 
which  is  provided  to  a  certain  extent.  The  major  drawback  of  third 
generation  languages  is  the  time  consimiing  need  for  writing  and  debugging 
a  nimiber  of  lines  of  code,  vdiich  makes  the  modification  of  complex 
systems  a  very  difficult  task. 

Forth-generation  languages  vary  greatly  in  their  power  and 

capabilities.  The  term  encompasses  software  tools  that  enable  the 

software  developer  to  specify  some  particular  aspect  of  the  software  at  a 

high  level.  The  tool  then  automatically  generates  the  code,  based  on  the 

user  specification.  Therefore,  while  some  4GLs  are  merely  query 

languages  or  report  generators,  others  are  able  to  build  a  complete 

application.  Some  4GIjS  are  referred  as  "nonprocedural  languages".  A 

nonprocedural  language  specifies  "what"  is  needed,  instead  of  focusing  on 

procedural  details  of  "how"  to  accomplish  the  action.  SQL  -  Structured 

Query  Language  is  a  relational  database  lainguage  that  is  an  example  of 

nonprocedural  language.  The  following  statement  is  a  complete  program  in 

this  language: 

SELECT  DRN,  TITLE 

FTiOM  DOCUMENT 

WHERE  CKGNAME  =  ’AFIT’ 
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AND  ISSUEDT  BETVEEN 
'10- JAN-89’  AND  ’20-FEB-89’; 

Oracle  RDBMS  uses  SQL  as  its  data  mEmipulation  lem^ua^e  and  offers 
additional  facilities  that  are  described  in  the  next  section. 

Oracle’s  Develognent  Tools 

Pressman  states  (Pressman,  1987:24)  that  4GL  environments  offer 
some  or  all  of  the  following  tools:  "nonprocedural  languages  for  data 
base  query,  report  generation,  data  manipulation,  screen  interaction  and 
definition,  and  code  generation  ..."  Hius,  Oracle  does  offer  a  4GL 
environment.  According  Lans,  Oracle’s  SQL  (SQL*Plus)  has  a  "noteworthy" 
large  number  of  additions  (Lans,  1988:283).  Besides  the  facilities 
offered  by  the  lemguage  itself  Oracle  provides  SQL*Forms,  a  tool  designed 
to  simplify  system/user  interaction,  and  SQL*Reporter,  a  tool  to  generate 
printed  documents  derived  from  the  database.  The  main  concepts  of 
SQL»Fonns  are  shown  in  Table  VI.  Form,  page  emd  block  concepts  are 
explained  in  the  next  paragraphs.  SQL  statements  were  already  introduced 
but  they  will  be  illustrated  sigain,  later,  together  with  triggers  and 
macros.  The  Reporter  facility  will  be  coomented  on  the  paragraphs  about 
the  modules  Print  Processing  Sheet  and  Print  Ibesaurus  Terms. 

Form.  A  form  is  a  screen  layout  that  presents  a  f ill-in- the-blanks 
arrangement  of  database  information.  It  permits  efficient  data  entry, 
update  euid  query  that,  otherwise,  would  require  the  operator  to  use  SQL 
statements.  Ibe  Oracle  program  that  creates  and  maintains  forms  is 
referred  as  SQL*Forms.  We  may  see  a  form  as  a  independent  set  of 
specif icaticxis  that  works  like  a  program.  Ibese  specifications  include 
screen  definitions,  tables,  queries,  integrity  rules,  data  validation, 

I 
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Table  VI.  SQL^Forms  Main  Concepts. 

-  form 

-  block 

-  page 

-  SQL  statements 

-  triggers 

-  macros 

etc,  vAiich  8u:e  made  in  a  interactive  manner  by  typing  statements  in 
"popup"  windows.  Forms  can  call  eetch  other,  but  only  can  exchange 
information  by  explicitly  defined  global  variables.  A  form  has  one  or 
more  blocks  and  one  or  more  pages.  Tbe  smallest  form  would  have  at  least 
one  "page"  and  one  "block."  A  form  is  saved  inside  the  database  files 
and  also  externally  in  a  ASCII  file  that  has  a  .IMP  extension. 
Applications  forms  can  migrate  to  a  different  computer  systen  that  also 
uses  Oracle  RDBMS  using  these  files. 

Block.  A  block  is  a  subset  of  a  form  that  provides  automatic 
insertion,  deletion,  update,  and  quiery  to  a  table  on  the  database  system. 
We  can  think  of  a  block  as  a  standard  procedure  available  in  a  program 
which  can  be  used  as  many  times  as  needed,  ai>d  tailored  to  fit  our 
necessities.  A  block  can  also  access  no  tables.  An  exanqple  is  a  form 
used  as  a  menu.  Ihe  single  block  only  contains  a  control  variable  that 
triggers  macro  statements  calling  the  "subordinate"  modules.  Note  that 
"subordinate  module"  only  means  a  module  that  is  called  by  another 
module,  which  does  not  imply  any  other  kind  of  interaction. 

A  block  has  a  "base  table"  but  can  contain  also  fields  from  other 
tables.  Automatic  operations  aire  supported  only  for  the  base  table. 
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'Ihose  fields  are  manipulated  by  specifying  triggers  and  SQL  statements  to 
act  on  them.  These  "extraneous"  fields  are  comnonly  used  to  access 
and/or  display  related  information,  euid  for  complex  data  validation  and 
integrity  enforcement.  Information  can  be  exchanged  among  blocks  by 
referring  to  a  field  in  a  "select  into  ..."  statement,  or  by  using  a 
macro  statement  as  "#OOPY  from_field  to_field". 

Pstge.  A  page  is  the  part  of  the  form  which  the  user  sees  on  the 
screen.  A  form  may  have  as  many  pages  as  are  necessary.  A  block  may 
occupy  only  part  of  a  page,  an  entire  page,  or  several  pages,  according 
to  the  necessity  auid  the  extension  and  nunber  of  fields  on  the  base 
table.  We  may  have  also  more  than  one  block  on  a  single  page.  Since 
each  block  has  its  own  base  table,  they  act  independently  of  eEu:h  other. 
It  is  possible  to  create  for  the  user  an  illusion  of  inteixiependency  by 
using  triggers  and  macros,  which  simulate  the  operator  strokes  by 
executing  hidden  statements.  Later  in  this  chapter,  some  examples  are 
given . 

Implanentation  Strategy 

It  was  necessary  to  define  an  in^lementation  strategy  to  guide  the 
development  effort.  The  steps  of  this  strategy  are  described  in 
Table  VII.  Each  one  of  them  is  explained  and  discussed  in  the  following 
paragraphs . 

Creation  of  Database  Tables ,  Clusters  and  Indexes 

The  inqilementation  begins  by  creating  the  tables  that  will 
ccffistitute  the  database.  Additional  tables  were  created  for  data 
validation  and  integrity  rules. 
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Table  VII.  Steps  of  the  Inqplementation  Strategy. 

1  -  CreaticHi  of  database  tables,  clusters  and  indexes. 

2  -  Developojent  of  a  experimental  module. 

3  -  Design  of  screen  templates. 

4  -  Distribution  of  screens  within  the  forms. 

5  -  Implementation  of  beisic  functions  and  simple  data  validations. 

We  added  to  the  tables  shown  in  Table  V  the  tables  SE^JUMBERS, 
RELNAME,  and  CLASSIFICATIOJ.  The  table  SE^nJIMBERS  is  used  to  generate 
Document  Reference  Numbers  automatically,  the  table  RELNAME  contains  the 
relationship  codes  and  complete  names,  and  finally  the  table 
CLASSIFICATION  that  contains  the  claissification  codes  with  their 
respective  complete  names.  In  the  preceding  chapters  we  have 
concentrated  on  the  conceptual  level.  However,  a  major  issue  is  the 
syst«n  performance.  The  performance  depends  not  only  on  the  efficiency 
of  the  data  structures  used  to  represent  the  data  in  the  database  but 
also  on  the  system  efficiency  in  accessing  and  manipulating  these  data 
structures.  Clustering  and  Indexing  were  ixsed  to  improve  the  system 
performance  and  are  explained  in  the  following  paragraphs.  The  file  used 
to  create  the  tables  Stfid  insert  initial  data  is  shown  in  Appendix  A. 

Clustering .  This  is  a  database  technique  and  Oracle  feature  that 
permits  both  access  time  and  disk  storage  space  savings. 

Access  Time.  Data  is  transferred  between  disk  storage  and 
main  memory  in  units  of  storage  called  "blocks".  Clustering  saves  access 
time  by  organizing  related  informatics  in  a  single  blcsk  and,  v4ien  a 
single  block  is  not  enough,  in  contiguous  blcxsks.  Ibe  performance  of 
join  queries  is  improved  because  rows  that  are  joined  are  stored 
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together.  Usually,  the  rows  of  a  table  are  represented  by  records  in  a 
file.  If  we  assign  the  records  randomly,  it  can  be  the  case  that  a 
different  block  must  be  accessed  for  each  row  needed. 

Disk  Storage  Space.  We  may  be  able  to  save  disk  storage 
space  by  storing  only  once  values  of  similar*  columns  that  were  defined  in 
different  tables.  Therefore,  to  be  clustered,  a  group  of  tables  must 
share  a  column  with  the  same  type,  length,  and  meaning.  Such  a  column  is 
called  "cluster  column".  Clustering  affects  the  way  tables  are 
physically  stored  on  disk,  while  having  no  effect  on  the  logical 
appearance  of  the  table.  Therefore,  it  is  not  necessary  to  know  the  name 
of  a  cluster  column  in  order  to  use  it  in  a  query.  The  program  will  use 
it  automatically,  whenever  the  query  that  was  requested  permits  its  use. 
Table  VIII  shows  the  tables  that  were  clustered  on  the  Docianent 
Reference  Number  column  (WN)  and  on  the  Term  column  (TERM).  All 


Table  VIII.  Clustered  Columns  and  Tables. 


Cluster  Name 

Colvmins 

Tables  Included 

CJDOCUMENT 

DRN 

DOOMENT 

REFERENCE 

ANNEX 

JOIN 

MICBOFIIW 

DOC_LOG 

HOLDER 

SUBJECT 

CJTERM 

TERM 

TERMS 

RELSHIPS 

NOTES 
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information  related  to  a  single  docunent  are  kept  together  providing  a 
minimal  access  time. 

We  decided  to  cluster  the  Subject  table  by  the  column  ERN  instead 
of  clustering  by  the  column  TETOI  because  join  queries  using  KiN  will  be 
more  frequent.  Suppose  we  are  interested  in  docvments  about  "jet  engine" 
and  "maintenance".  The  query  has  to  find  all  the  documents  indexed  by 
"jet  engine"  and  then  verify  vhether. those  documents  are  also  indexed  by 
"maintenance" .  If  we  suppose  the  query  accesses  1000  documents 
registered  under  the  term  "jet  engine"  and  that  each  docvanent  is  indexed 
by  5  terms  in  average,  the  total  nunber  of  8ux:esses  by  TERM  key  would  be 
1000,  and  the  total  number  of  accesses  by  the  DRN  key  would  be  5000. 
Actually,  the  number  of  accesses  is  smaller  than  5000  because  the 
subquery  stops  when  a  positive  comparison  is  resushed. 

Sometimes  a  cluster  that  contains  just  one  table  also  saves  disk 
storage  space.  This  would  be  the  case  of  the  table  Terms,  vhere  a  same 
value  of  CLiASSCD  is  repeated  on  the  rows  of  all  terms  pertaining  to  that 
class.  Since  nested  clustering  is  not  possible,  in  place  of  clustering 
by  CLASSCD  we  preferred  to  keep  together  all  information  related  with  a 
same  TERM.  In  Eiddition  to  the  organi2ational  advantages  of  clustering, 
the  DBMS  creates  an  index  on  the  clustered  colvinn(s)  that  increases  the 
access  speed. 

Indexing .  An  index  to  a  table  helps  to  find  information  quickly. 
The  program  can  "look  up"  the  rows  in  an  index  to  the  table.  Otherwise, 
it  would  have  to  scan  all  the  rows  of  the  table.  Indexing  a  table  may 
reduce  the  time  requested  to  perform  a  query,  mainly  if  the  table  is 
large..  On  the  other  hand,  if  the  table  hsis  a  few  columns  (a  few  may  be 
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considered  as  less  than  two  hundred)  the  overhead  involved  in  using  an 
index  will  probably  exceed  the  time  saved.  Another  use  of  indexing  is  to 
guarantee  that  a  colunn  of  a  table  contains  unique  valiies  (as  we  want  for 
the  primary  key  of  a  table),  although  we  did  not  use  the  index  feature  on 
this  purpose  (we  used  the  "primary  key"  feature  of  SQL^Fonns).  By 
contrast,  clustering  does  not  enforces  uniqueness.  Therefore,  we  used 
the  indexing  technique  on  the  columns  expected  to  be  frequently  accessed 
by  queries,  whenever  clustering  was  not  possible,  not  necessary,  or  not 
efficient  enough.  We  also  used  indexing  on  the  columns  where  speed  is 
more  important  than  saving  disk  storage  space. 

Table  IX  shows  the  indexes  that  were  created  on  the  database 
tables.  Alike  clustering,  the  user  does  not  need  to  know  vAiether  a 
column  is  indexed,  nor  the  name  of  a  index.  If  an  index  exists,  the 
query  will  use  it  automatically,  whenever  possible. 

Table  IX.  Indexed  Columns  and  Tables. 


Index  Name 

Column 

Table  Name 

IJTERM 

TERM 

SUBJECT 

I_P_NIMBER 

P_NUMBER 

DOCUMENT 

I_IDNR 

IDNR 

DOCUMENT 

I  ORGNAME 

ORGNAME 

DOCUMENT 
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Module 


Development  of  an  Experimental 

This  step  was  to  help  me,  as  a  new  Oracle  developer,  to  learn  the 
capabilities  of  the  Oracle  system  and  to  choose  a  suitable  style  to  be 
used  on  all  the  other  modules.  The  Enter  DocLment  module  was  chosen  to 
be  the  experimental  module.  In  this  phase  1  became  familiar  with 
defining  forms,  defining  database  and  control  fields,  choosing  field 
attributes,  establishing  data  validation,  using  triggers,  atnd  using  SQL 
statements  inside  a  form.  SQL*Forms  does  not  provide  means  for  copying 
trigger  steps  from  one  trigger  to  another  one,  nor  triggers  from  one 
block  to  einother  block  in  the  same  form.  This  ability  is  useful  when 
standardization  of  commands  and  messages  is  needed. 

To  overcome  this  deficiency,  peurt  of  the  work  weis  done  directly  on 
the  IMP  files.  An  IMP  file  (.IMP  suffix)  is  an  intermediate  text  file 
that  contains  a  form  description  used  by  the  system  to  generate  form 
files  (.FRM  suffix),  to  load  the  form  description  into  the  SQL*Forms 
program,  or  to  convert  the  form  description  into  a  database  format  (vhich 
is  kept  in  several  Oracle  system  tables ) . 

After  doing  the  modifications,  the  program  Interactive  Application 
Converter  -  lAC  was  used  to  convert  the  IMP  file  into  a  database  format. 
The  program  Interactive  Application  Generator  -  lAG  was  used  to  generate 
the  form  file.  Another  possibility  investigated  was  a  manory  resident 
text  editor  to  cut  and  paste  on  the  SQL»Forms  Paint  Screen.  This 
process  permits  SQL  statements  to  be  copied  between  fields  and  blocks  and 
also  between  forms.  Its  disadvantage  is  the  abrupt  end  of  the  SQLtForm 
program,  losing  the  modifications  alreauiy  done,  vAien  it  does  not  have 
enough  memory  space  to  keep  those  changes.  To  avoid  this  loss  it  is 
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necessary  to  save  the  form,  exit  from  SQL*Foniis,  and  enter  again. 
Therefore,  due  to  t’.e  memory  space  used  the  resident  program,  a  user 
should  save  the  work  frequently. 

Design  of  Screen  Templates 

Table  X  shows  the  conventions  used  in  template  design.  The  screens 
were  designed  outside  SQL*Forms,  before  creating  the  forms  that  would  use 
them.  They  were  designed  using  a  text  processor. 

Figure  20  shows  an  example  of  a  menu  screen  used  in  the  system.  To 
give  the  user  the  notion  of  which  level  he  or  she  is  working,  it  used  a 
windowing  like  menu  system.  Some  menus  go  one  level  deeper  by  having 
another  submenu  window  that  partially  covers  the  previous  menu. 

The  system  has  around  30  different  screens  (or  peiges)  and  the  style 
used  for  all  of  them  hats  the  following  chai*acteristics : 
use  of  a  windowing  menu  tree 
a  single-line  box  surrounding  no  menu  screens 
enumeration  of  blocks  in  a  same  screen 
sepiaration  of  blocks  in  a  same  screen  by  a  double  line 
module  name  on  the  left  bottom  comer  of  the  screen 
main  keys  used  on  the  module  at  the  bottom  of  the  screen 
All  screens  are  shown  in  Appendix  B. 

Distribution  of  Screens  Within  the  Forms 

To  facilitate  the  identification  of  forms,  blocks,  and  pages,  the 
method  that  follows  was  used  in  naming  the  screen  templates.  Eakch  screen 
represents  a  module  of  the  proposed  system  { see  Figure  11).  The  screen 
name  is  the  code  that  corresponds  to  the  system  module  (ex:  AO,  A34, 
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Table  X.  Symbols  Used  in  the  Screen  Templates. 


C  fields  may  contain  any  combination  of  letters,  digits,  blank 
spaces,  punctuation,  and  special  characters. 

9  field  may  contain  any  number. 

DD  day  of  the  month. 

MCXs  month  of  the  year,  as  JAN  for  instance. 

YY  last  two  digits  of  the  current  year. 

HH  hours  of  the  day,  in  a  24  hours  format. 

MI  minutes  of  the  hour. 

()  enclosing  a  field  definition,  as  "(CCX3C)"  for  instance,  to 
represent  fields  that  cannot  be  accessed  by  the  operator. 
Protected  field. 

->  at  one  end  of  a  field,  as  "CCCC-y  for  instance,  or  above  the 
field  name,  to  indicate  that  the  field  length  is  longer  than  the 
display  length.  The  operator  can  use  the  arrow  key  to  scroll  the 
field  horizontally. 


etc).  Each  screen  has  its  name  written  on  the  left  bottom  comer  of  the 
template.  Therefore,  each  screen  template  also  corresponds  to  a  "page" 
of  a  "form"  on  the  Oracle  syst^.  When  a  form  has  only  one  page  (it 
corresponds  to  just  one  system  module)  the  name  of  the  form  is  identical 
to  the  name  of  the  screen  it  represents.  When  the  same  form  has  more 
than  one  page  (more  than  one  screen)  two  situations  may  arise: 

1.  Each  page  constitutes  a  different  module.  The  form  borrows  the 
name  of  the  first  page.  Usually,  the  first  pEige  corresponds  to  a 
"parent"  module  and  the  other  pages  to  "children"  modules,  with  the 
same  structure  of  the  proposed  system. 

2.  A  same  module  spans  more  than  one  page  (never  more  than  two  pages). 
Each  screen  has  the  same  basic  name  but  differs  on  suffix.  Ihe 
first  pe^e  has  a  suffix  "-1"  and  the  second  page  has  a  suffix  "-2". 
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DOCUMENT  CONTROL  AND  RETRIEVAL  SYSTEM 


MAIN  MENU 


Consult  Database 


1  -  Register  Docuael Look  Up  Thes.  Teras 


2  -  Update  Database 


3  *  Consult  Databae 


4  -  Maintain  Thesai: 


1  -  Classes 

2  -  Teras  A  Relations 

3  -  Teras  within  Class 

4  -  Teras  Sequentially 


Type  your  choice: 


Press  Enter  to  accept 
Ctrl-Z  to  exit 


Figure  20.  Exaaple  of  Three  Level  Menu. 

A  page  aay  contain  one  or  aore  than  one  blocks.  Blocks  that  have  a 

base  table  are  referred  to  by  the  base  table  naae.  Blocks  that  do  not 

have  a  base  table  are  usually  alone  in  a  page  and  are  referred  to  by  the 

aodule  naae  which  they  represent. 

The  criteria  used  to  place  aodules  (pages)  in  the  saae  fora  was: 

necessity  of  coaaunication  between  aodules.  A  block  placed  in 
screen  "A"  aay  need  to  copy  the  value  of  a  field  which  is  placed 
soaewhere  in  screen  "B".  Blocks  coaaunicate  aore  easily  when 
placed  in  the  saae  fora.  Coaauni cat ions  between  foras  have  to  be 
done  using  global  variables  that  have  a  constrained  use. 

necessity  of  reducing  the  loading  tiae  of  a  called  aodule.  Soae 
aodules  are  expected  to  switch  frequently  froa  one  aodule  to  the 
other.  We  shall  reduce  the  waiting  tiae  as  auch  as  possible.  This 
is  the  case  of  the  aenu  tree  which  was  placed  in  the  saae  fora  to 
reduce  the  tiae  between  displaying  the  aain  aenu  and  a  subaenu. 


The  criteria  used  to  place  aodules  in  distinct  foras  was: 
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independence,  that  is,  there  is  no  need  of  acx^essing  a  field 
pertaining  to  another  block  in  a  different  screen.  The  module  is  a 
complete  and  functional  unit. 

sinqplicity.  Although  a  module  may  logically  correlate  to  other 
modules,  if  there  is  no  physical  dependency,  making  it  a  single- 
page  form  simplifies  maintenance. 

The  arranganent  suinnarized  in  Table  XI  was  obtained  by  applying  the 
heuristic?  described  above.  The  table  maps  system  modules  to  pages  of  a 
form.  Some  forms,  as  form  AO  for  instance,  encompass  more  than  one 
module.  In  form  AC  esu:h  module  is  a  page.  On  the  other  hand,  a  page  may 
encompass  more  than  one  block,  as  form  A241  page  #1  for  instance. 
Coordinate  or  control  blocks,  which  do  not  have  a  base  table,  are 
indicated  in  the  table  by  a  star  preceding  the  block  name.  Form  AO,  in 
spite  of  having  several  screens  and  blocks,  does  not  have  any  "base 
table".  The  same  happens  with  module  A36.  In  spite  of  eux:essing  several 
tables  to  calculate  the  statistics,  it  does  not  have  a  base  table. 

Implementation  of  Batsic  Functions  and  Simple  Data  Validations 

For  the  sake  of  simplicity,  the  implementation  of  forms  was  divided 
into  two  leases.  In  the  first  stage  the  forms  were  created  but  without 
the  use  of  triggers  and  imbedded  SQL  statements,  except  vdien  they  were 
strictly  necessary  to  implement  basic  functions.  Table  XII  lists  the 
tasks  done  in  this  phase. 

Implementation  of  Complex  Data  Validations  and  Integrity  Rules 

Integrity  constraints  and  validation  criteria  were  condensed  by 
module  to  facilitate  the  forms  development  and  to  provide  means  for  their 
testing.  Constraints  were  listed  according  to  significant  inpxit 
conditions.  Some  of  these  conditions  were  Insertion,  Update,  Deletion 
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Table  XI.  Screen  Distribution  within 

the  Forms 

Module  Name 

Form 

Screen 

Pg#  C  Block(s)  1 

Main  Menu 

AO 

AO 

1 

*  AO 

Register  Document 

tt 

A1 

2 

*  A1 

Update  Database 

»» 

A2 

3 

*  A2 

Transfer  Custody 

tt 

A25 

4 

*  A25 

Consult  Database 

ti 

A3 

5 

*  A3 

Locdi  up  Thesaurus  Terms 

tt 

A32 

6 

*  A32 

Maintain  Thesaurus 

tt 

A4 

7 

»  A4 

Enter  Document 

All 

All 

1 

DOCUMENT, 

REFERENCE,  ANNEX. 

Print  Processing  Sheet 

A12 

A12 

1 

*  A12 

Generic  Update 

A21 

A21-1 

1 

DOCUMENT 

REF^RENOEi  f  ANH£X 

A21-2 

2 

HOLDER,  DOC  LOG 

Change  Validity 

A22 

A22 

1 

DOCUMENT 

1  Process  Docunent  Destruction  A23 

A23 

1 

DOCUMENT 

Join  Doctments 

A24 

A24 

1 

JOIN 

Transfer  Department  Custody 

A251 

A251 

1 

D0C_L0G 

Transfer  Holder  Name 

A252 

A252 

1 

HOLDER 

Update  Microfilm  Data 

A26 

A26 

1 

MICROFILM 

Subject  Indexing 

A27 

A27 

1 

SUBJECT 

Browse  by  Holder 

A31 

A31 

1 

HOLDER, DOCUMENT 

Look  Up  Classes 

A321 

A321 

1 

CLASSES 

Look  Up  Terms/Relationships 

A322 

A322 

1 

TE»B,RELSHIPS 

Look  Up  Terms  within  Classes 

A323 

A323 

1 

TERMS 

Look  Terms  Sequentially 

A324 

A324 

1 

TERMS 

Browse  by  Header 

A33 

A33 

1 

DOCUMENT 

Browse  by  Subject 

A34 

A34 

1 

SUBJECT , DOCUMENT 

Retrieve  Document 

A35 

A35-1 

1 

DOCUMENT, SUBJECT 

A35-2 

2 

REFERENCE , ANNEX 

MICROFILM, JOIN, 

HOLDER, DOC  LOG. 

Show  Statistics 

A36 

A36 

1 

*  A36 

Maintain  Classes 

A41 

A41 

1 

CLASSES 

Maintain  Terms 

A42 

A42 

1 

TERMS, NOTES 

Maintain  Relationships 

A43 

A43 

1 

REIDHIPS 

Print  Thesaurus  Terms 

A44 

A44 

1 

*  A44 

and  ^jery.  Appendix  C  shows  the  integrity  rules,  Appendix  B  the  screen 
tenqplates  vhere  the  rules  apply,  and  Appendix  D  some  of  the  triggers  that 
implement  the  integrity  rules.  Actually,  Appendix  D  does  not  encaiiq»ss 
all  existing  triggers,  due  to  their  great  nimiber.  Those  listed  are 
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Table  XII.  Tasks  performed  in  the  Implementation  of  the  Basic  Functions. 


Creation  of  forms,  blocks  and  fields; 

Specification  of  field  attributes  usin£  the  Specify  Attributes 
feature  of  SQL*Forms; 

Data  validation  of  field  input,  using  the  Specify  Validation 
feature; 

Definition  of  the  default  ordering  in  queries  using  the  Default 
Ordering  Window; 

Specification  of  triggers,  using  the  Trigger  Step  feature. 


samples  of  a  class  of  integrity  enforcement. 

To  illustrate  the  accomplishment  of  integrity  rules,  eui  example  weis 
selected  from  module  A251  -  Transfer  Custody  -  Department.  The  following 
integrity  rule  is  listed  under  the  insertion  input  condition  (Appendix  C, 
page  114): 

-  Set  the  document  history  status  equal  ”A”  (alteration)  if  there 
exists  a  transference  of  the  document  in  which  the  sending  department  is 
different  from  the  receiving  department  in  the  previo-':>  row.  Otherwise, 
set  the  document  history  status  equal  "N"  (normal).  Example:  assume 
there  are  two  rows  in  the  Doc_Log  table,  ordered  by  DRN,  Date,  and  Time, 
in  ascending  order,  with  these  values: 


E«N 

Date 

Time 

Send  Dep 

Rec  Dep 

99999999 

DATEl 

TIMEl 

DEPl 

DEP2 

SAME  DRN 

DATE2 

TIME2 

DEP3 

DEP4 

The  underlined  departments  should  be  the  same.  As  they  are  not  the  saune, 
set  the  document  history  status  equal  "A" . 

Figure  21  shows  the  trigger  step  that  verifies  the  rows 
correspcHiding  to  the  document  being  trauisferred,  in  the  table  DOC_LOG,  to 
enforce  the  integrity  rule  described  above.  Tbe  trigger  step  was 


e.'vtraujted  from  the  A251.INP  file  that  describes  the  form  A251,  au^  is 


♦POST-INSERT 

;SQL> 

SELECT  * 

F«0M  DOC_LOG  Y 

WHERE  EXISTS  (SELECT  » 

FROM  DOC_LOG  X 

WHERE  IXuN  -  :DRN 

AND  Y.HW  =  I»N 

AND  Y.SEND_DEP  <>  RECJDEP 

AND 

TO_NlWBER(TO_CHAR  (Y.LDATE, ’ J’ ) 

1!  SUBSTR(Y.LT»ffi,l,2) 

SUBSTR(Y.LTIME,4,2)) 

(SELECT  MIN  (ALL  TO_NlJMBER(TO_CHAR  (LDATE.’J’) 
!!  SUBSTR(LTIME,1,2) 

: :  SUBSTR(LTIME,4,2))) 

FROM  DOCJjOG 

WHERE  DRN  =  :E«N 

AiND  TO_CHAR(LDATE, '  J' ) 

SUBSTR(LTIME,1,2) 
il  SUBSTR(LTIME,4,2) 

> 

TOJCWAR  (X.LDATE.'J') 

!!  SUBSTR(X.LTrME,l,2) 

11  SUBSTR(X.LTIME,4,2) 

) 

) 

/ 

; Message  if  value  not  found  : 

$SET_ALTERATI(»4  $SET_NC*MAL 


Figure  21.  Trigger  Step  to  Validate  a  Document  Transference. 


also  listed  in  Appendix  D,  page  146.  ITie  step  is  pert  of  a  "Post-Insert" 
trigger.  This  means  that  it  is  executed  after  the  operator  has  inserted 
the  new  row  in  the  table  Doc_Log,  corresponding  to  the  transference  being 
made.  Observe  the  Isist  line  of  the  step.  The  first  "$"  symbol  indicates 
the  label  of  the  next  step  to  be  performed  if  this  step  succeeds.  The 
second  "$"  indicates  the  failure  label.  Hie  step  shown  does  not  set  the 
docunent  history  status  itself;  but,  if  there  exists  a  row  where  the 
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sending  departjnent  is  different  from  the  receiving  department  of  the 
previous  row  the  step  succeeds  and  the  success  label  deviates  the  trigger 
to  the  step  that  will  set  the  status  equal  "A"lteration.  On  the  other 
hand,  even  if  the  history  status  was  alteration,  if  the  insertion  of  the 
present  row  brings  consistency  to  the  docunent  log  (suppose  the  missing 
row  was  introduced)  the  step  fails,  causing  the  trigger  to  set  the 
history  status  "N"onnal.  Therefore,  this  step  accommodates  transference 
insertions  that  aire  made  out  of  order. 

The  SQL  query  that  analyses  the  rows  is  one  of  the  most  complex 
queries  in  the  entire  system.  Note  that  it  gives  to  the  table  DocJLog 
the  "aliases"  Y  and  X  to  make  comparisons  with  distinct  instantiations  of 
the  table  DocJLog.  The  logical  expression  "exists"  is  evaliiated  Eis  true 
if  the  subquery  returns  at  least  one  row,  and  false  if  not.  The  date 
(LDATE)  is  transformed  to  Julian  date  and  is  concatenated  to  the  time 
(LTIME)  without  the  coinna.  This  makes  comparisons  between  date-times 
easier. 

The  analysis  is  made  by  selecting  each  row  of  the  document  being 
transferred.  This  row  is  compared  with  the  row  that  has  the  "MIN"imum 
date-time  value  among  those  rows  that  have  the  date-time  value  greater 
than  the  row  that  was  selected  for  the  comparison.  Ihe  comparison 
verifies  that  the  SendJDep  of  the  selected  row  is  different  from  the 
RecJDep  of  the  "greater’s-smallest"  row.  This  way,  each  row  is  compared 
with  the  row  that  has  the  date-time  value  immediately  greater. 
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Implementation  of  Printed  Reports 


Although  all  qxieries  displayed  on  the  screen  may  be  output  to  a 
printer  attached  to  the  microcomputer  terminal  there  are  two  forms 
specially  designed  to  generate  printed  reports.  They  aure  the  A12,  Print 
Processing  Sheet  and  the  A44,  Print  Thesaurus  Terms.  While  it  is  easy  to 
extract  reports  using  line  comands  in  SQL*Plus,  we  need  standardized 
reports  in  special  situations.  The  first  is  the  processing  sheet  that  is 
attached  to  each  document,  the  second  is  the  printed  thesaurus 
dictionary,  which  may  be  used  for  off-line  docijnent  indexing.  These 
reports  are  generated  using  the  Oracle  tool  SQL*Report,  a  procedural 
system  compose ’  of  two  programs .  The  "Report  Generator  -  RPT" ,  is  used 
to  extract  information  from  the  database  and  the  "Reporter  Text  Formatter 
is  used  to  fonnat  the  report.  To  generate  a  report  we  create  a  source 
file  which  is  successively  compiled  by  both  programs.  Appendix  E  lists 
the  object  file  of  the  processing  sheet  and  two  of  the  four  reports 
generated  for  the  thesaurus.  The  ranaining  object  files  are  not 
presented  because  they  are  only  variations  of  the  other  ones.  Note  that 
these  reports  are  executed  from  inside  SQL*Fonns  with  no  need  of  quitting 
the  program.  The  reports  are  printed  simultaneously  to  the  printer  and 
to  disk  files.  The  disk  files  have  the  same  name  of  the  generating  Form 
concatenated  with  the  corresponding  menu  number,  euid  a  suffix  LIS. 
Therefore,  the  program  All  which  gives  j-eport  options  1,  2  and  3  prints 
reports  to  the  files  All_l.LIS,  A11_2.LIS  and  All_3.LIS.  Each  time  the 
8£une  report  is  generated  it  overwrites  the  previous 

report.  Figure  22  gives  a  sample  the  format  of  the  report  A44_3.LIS 

vhich  orders  terms  by  their  hierarchical  relationship.  For  demonstration 
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TOESAIMJS  REFa?r  A44_3  - 

(»DER  BY  TERM  HIERARCHICAL  ASSOCIATION 

08/03/89  03:53 

PAGE  1 

Level  Term 

1.  HOOT 

2.  DOOMENT 

OCWTROL 

3.  AO 

4. 

A1 

5. 

All 

5. 

A12 

4. 

A2 

5. 

A21 

5. 

A22 

5. 

A23 

5. 

A24 

5. 

A25 

5. 

A25 

6.  A251 
6.  A252 

5. 

A26 

5. 

A27 

4. 

A3 

5. 

A31 

5. 

A32 

6.  A321 
6.  A322 
6.  A323 
6.  A324 

5. 

A33 

5. 

A34 

5. 

A35 

5. 

A36 

4. 

A4 

5. 

A41 

5. 

A42 

5. 

A43 

5. 

A44 

END  OF  REPCKT 

Figure  22.  Report  A44_3.LIS,  Terms  by  Hierarchical  Association. 


purposes,  the  names  of  the  modules  that  compose  the  proposed  system  were 
entered  as  thesaurus  terms,  creating  the  same  hierarchical  relationships 
that  exist  in  Figure  11.  The  report  traverses  the  hierarchical  tree  in 
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preorder;  giving  the  term  name  and  the  term  level  in  the  hierarchical 
relationship  tree. 


Design  of  the  Document  Transference  Receipt 

When  a  document  is  transferred  from  one  department  to  another  the 
updates  of  tables  Holder  and  DocJLog  are  made  using  the  module  A251, 
Transfer  Custody  -Department.  This  task  may  be  assigned  to  the  Protocol 
Section,  to  the  Archive  Section,  or  even  to  both  of  them.  Whatever 
section  is  chosen,  they  cannot  afford  to  have  a  computer  station 
dedicated  only  to  enter  document  transferences.  But,  because  we  do  not 
want  to  introduce  delays  in  the  document  processing,  we  create  a  document 
transference  receipt. 

The  proposed  model  is  shown  in  Figure  23.  The  sending  department 
may  plawiie  in  one  receipt  more  than  one  document.  Also,  documents  in  the 
S6une  receipt  may  have  different  destinations.  Someone  in  the 
transferring  department  fills  the  receipt  fields  except  those 
corresponding  to  the  transference  time,  receiver  name,  and  initials.  The 
distribution  man  distributes  the  documents,  collecting  the  receivers' 
names  and  initials.  He  also  enters  the  Time  the  transference  was  made. 
Upon  completion,  he  leaves  a  copy  in  the  section  assigned  to  enter 
document  transferences  and  keeps  the  original  with  him,  after  noting  the 
name  and  initials  of  the  transference  station  responsible. 

Integration  and  Testing 

TVro  kinds  of  tests  were  performed;  individual  test  and  integrated 
test.  Tbe  first  one  was  concerned  with  the  proper  execution  of  the 
fundamental  operations.  Tbe  second  one,  executed  after  integrating  the 
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Figure  23.  DocumenL  Transference  Receipt. 

module  into  the  system,  was  concerned  with  details  and  boundaries.  The 
rationale  for  creating  test  cases  was  beised  in  the  "Equivalence  Claisses" 
and  "Boundary- Value"  testing  techniques.  Both  are  largely  heuristic 
methods  that  provide  the  tester  with  a  set  of  guidelines.  The  task  u&s 
simplified  because  Oracle  itself  does  most  of  the  input  validation. 
However,  it  is  necessary  to  set  the  proper  options  using  SQL*Forms  to 
have  those  validations  performed.  Complex  validation  and  integrity  rules 
are  entered  by  using  embedded  SQL  statements  inside  the  forms  (triggers). 
To  verify  vdiether  these  operations  were  properly  executed  was  a  more 
difficult  task.  Some  triggers  update  tables  that  are  not  presented  on 
the  form’s  screen.  In  this  situation  it  is  necesssury  to  exit  the  testing 
module  to  euxiess  those  tables.  Some  queries  were  tested  before  being 
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inserted  into  the  form.  Tliese  complex  queries  were  developed  using 
SQL*Plus.  When  the  desired  results  were  obtained,  the  query  was 
integrated  to  the  form  with  just  a  few  modifications. 

The  data  validation  and  integrity  rules  listed  in  Appendix  C  were 
largely  used  not  only  in  developing  the  forms  but  also  in  testing  them. 

Table  Locking 

When  an  operator  queries  a  block  or  updates  a  record  in  a  block  the 

J 

1 

base  table  for  the  block  is  automatically  locked  by  SQLtFonns  in  "share 
update  mode" .  This  permits  more  than  one  operator  to  update  the  table 
concurrently.  When  a  trigger  acts  in  a  table,  SQL*Forms  issues  an 
"exclusive  lock"  on  that  table.  If  the  table  has  already  been  locked  in 
share  update  mode  by  another  form,  this  will  cause  an  error  with  the 
consequent  roll  back  of  the  operations  not  conmitted  yet.  To  avoid  this 
situation  a  kind  of  a  "two  {^ase  locking  piX)tocol"  mixed  with  a  "grajrfi- 
based  protocol"  was  used  to  "soften"  the  locking  level.  It  is  a  two 
phase  locking  protocol  in  the  sense  that  locks  su^quired  are  not  released 
until  a  commit  has  been  issue  by  the  trigger  or  by  the  operator.  It  is  a 
grap^-based  protocol  because  tables  are  accessed  following  an  established 
partial  ordering. 

Table  XIII  shows  the  table  ordering  used  in  triggers  to  delete  and 
update  data  that  are  not  accessed  from  the  block  base  table. 

Implementation  Difficulties 

The  most  significant  difficulty  faced  in  the  inqplementation  phase 
came  from  a  "bug"  in  the  SQL*Form.  The  "Trigger  Step  Attribute  Window" 
is  a  feature  used  when  defining  triggers.  In  this  window  it  is  possible 
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Table  XIII.  Partial  Ordering  for  Locking  Tables. 


Table  Name 

Document 

Reference 

Annex 

Doc_Log 

Holder 

Join 

Microfilm 
Subject 
Classes 
Terms 
Notes 
Relships 
SeqNumbers 
To  Delete 


to  define  a  success  and/or  a  failure  label  to  instruct  the  trigger  about 
the  next  step  to  be  executed  after  performing  the  actual  trigger  step. 
According  the  Oracle  manual  "SQL*Forms  -  Designer’s  Reference"  (Zussmsm 
and  others,  1987:8-29)  we  may  define  only  the  failure  label,  if  desii^ed. 
In  this  case  vdien  the  trigger  succeeds  it  is  supposed  to  proceed  to  the 
next  step  and  when  it  fails  it  is  supposed  to  proceed  to  the  failure 
label.  Actually,  if  only  the  failure  label  was  defined,  the  next  time 
the  form  was  loaded  into  the  SQL*Forms,  that  label  would  not  be  saved 
into  the  INP  file.  This  makes  the  trigger  proceed  to  the  next  step  on 
success  or  failure.  There  are  some  special  conditions  that  avoids  this 
behavior.  If  when  loading  that  form  you  recall  that  trigger  step  and 
open  that  Trigger  Step  Attribute  Window  again,  the  label  will  be  recorded 
back  in  the  INP  file.  This  "bug"  causes  confusing  form  behavior.  The 
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form  is  tested  and  it  is  working  well.  Later,  when  some  modification  is 
introduced,  the  form  starts  to  commit  errors  not  related  to  the 
modification  that  was  done.  When  the  designer  recalls  the  trigger  to 
inspect  the  cause,  he  finds  the  single  label  there  and  no  reeison  for  the 
anomaly.  But  just  because  the  trigger  was  recalled,  the  label  is 
recorded  back  in  the  IMP  fi]e  and  the  form  starts  working  well  again. 

The  developer  becomes  afraid  of  doing  modifications  in  a  form.  It  seems 
that  whenever  a  form  is  loaded  it  starts  making  errors  that  stop  only 
when  the  form  is  completely  revised,  even  when  nothing  wrong  is  found. 

The  solution  is  just  to  create  a  success  label  also,  whenever  a  failure 
label  becomes  necessary.  Success  labels  alone  do  not  cause  any  problems. 
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VI .  Conclusion 


Although  the  final  evalioation  hsis  to  be  made  by  the  user,  a  natural 
way  of  measuring  how  well  the  system  fulfills  the  requirements  is  by 
comparing  the  implementation  to  the  system  requirement  specifications. 

System  Evaluation 

A  complete  design  and  implementation  of  a  complex  database  is  a 
difficult  and  time  consuming  task.  Even  the  requirements  specification 
is  a  difficult  task  when  the  user  does  not  know  exactly  what  is  needed, 
which  frequently  happens.  The  essence  of  the  requirements  are  the 
necessity  of  a  standard  software  to  be  run  on  PC  like  microcomputers, 
able  to  answer  the  questions  presented  in  the  Requirements  Specification 
chapter,  which  are  replicated  in  Table  XIII  for  convenience.  Because  of 
this  loose  definition  the  evaluation  is  somewhat  subjective.  To  show 
that  the  proposed  system  fulfills  the  needs  the  following  paragraphs 
contrast  the  systan  with  those  questions. 

Building  the  Databeise.  The  most  important  tasks  in  the  system  are 
those  related  to  collecting,  organizing,  and  uxxlating  the  information 
about  documents  received  and  sent.  Tbree  of  the  four  main  modules  in 
which  the  proposed  system  is  divided  are  dedicated  to  these  tasks.  The 
fourth  module,  "Consult  Database",  concentrates  the  programs  used  to 
retrieve  the  stored  information.  In  spite  of  their  impord^ance,  most 
end-users  will  not  have  access  to  the  maintenance  modules.  Ibey  will 
only  use  the  module  "Consult  Database”  to  retrieve  document  information. 
Because  of  these  system  characteristics  and  because  the  system 
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Table  XIV.  Dcx^ument  Control  Fundamental  Questions. 


a.  Ifas  the  organization  received  this  document? 

b.  What  is  this  document  about? 

c.  Where  is  this  document? 

d.  Which  sections/departments  have  alreeuiy  processed  this 

document? 

e.  Who  is  currently  analyzing  this  document? 

f.  Which  documents  may  I  destroy? 

g.  Which  documents  are  related  to  this  subject? 

requirements  are  expressed  as  end-users’  questions  about  documents,  the 
capacity  of  responding  well  to  those  questions  depends  on  having  the 
right  information  stored  in  the  database,  and  the  flexibility  in 
extracting  information. 

Answering  the  Questions.  The  goal  of  the  maintenance  modules  is  to 
keep  a  knowledge  base  that  contains  all  information  needed,  logically 
divided  into  three  partitions: 

-  Control  Database 

-  Catalog  Database 

-  Subject  Databeise 

The  standard  way  of  extracting  this  information  is  using  any  of  the 
"Consult  Database"  modules.  The  basic  Consult  Database  module  is  the 
"Retrieve  Docunent".  All  docxmient  attributes  are  available  in  this 
module.  In  spite  of  that,  some  of  the  other  consul t-databeise  modules  may 
be  more  appropriate,  depending  on  the  type  of  seEux:h  being  performed. 

All  consul t-databeise  modules  use  embedded  SQL  statements.  If  some 
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special  situation  arises,  a  specific  SQL  query  may  be  entered,  using 
SQL»Plus  comnand  line.  This  kind  of  query  only  requires  of  the  user  a 
better  understanding  of  SQL  statements.  Ibis  flexibility  offered  by  the 
SQL  languEige  enforces  the  necessity  of  having  all  relevant  information 
about  the  document  collection  in  the  database. 

The  "control  database"  encompasses  information  about  document 
destination,  processing,  validity,  and  custody.  It  hsis  the  information 
needed  to  answer  questions  "c" ,  "d",  "e",  aixi  "f".  Besides  the  "Retrieve 
Document"  module,  answers  for  questions  "c"  and  "e"  may  also  be  obtained 
using  the  module  "Browse  by  Holder”. 

The  "catalog  database"  encompasses  information  about  document 
identification  attributes  entered  into  the  system  by  the  module  "Register 
Document",  it  has  the  information  needed  to  answer  question  "a"  and 
question  ”b".  One  can  query  browse  the  database  with  identification 
arguments  by  using  the  module  "Browse  by  Header". 

Finally,  the  "subject  databeise"  encompasses  all  information  needed 
to  search  for  documents  about  a  subject  of  interest.  One  can  find  the 
answer  to  question  "g"  by  querying  the  databeise  using  thesaurus  terms  as 
arguments.  This  may  be  accomplished  using  the  module  "Browse  by 
Subject" . 

Evaluation  Conclusion. 

By  comparing  the  needs  with  the  proposed  system,  one  concludes  the 
proposed  systan  well  satisfies  the  requirements.  It  satisfies  the 
requirements  because  it  has  procedures  easily  implementable ,  to  store  all 
data  necessary  to  respond  the  questions  presented  in  the  specification; 
because  it  provides  standard  and  alternative  ways  to  query  about  those 
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questions;  and,  finally,  because  it  is  appropriate  for  a  standard 
software,  since  its  procedures  are  based  on  official  issues  and  it  was 
implemented  with  a  DBMS  available  for  PC  like  microcomputers  and  several 
other  computer  hosts. 

Extra  Features .  The  system  not  only  satisfies  the  requirements  but 
also  provides  additional  information  and  control.  As  an  example  we  have 
the  DRN  Verifier,  vrtiich  was  introduced  to  avoid  incorrect  ujxlates  by 
having  the  operator  enter  a  different  DRN  than  that  of  the  document  being 
updated.  Another  example  of  additional  information  and  control  is  the 
"Show  Statistics"  module.  It  is  impossible  to  detect  instability  in  the 
system,  to  tell  whether  the  document  processing  is  becoming  slower,  or  to 
take  corrective  actions  if  there  are  no  standards  to  compare  with.  The 
referred  module  provides  information  for  this  kind  of  management.  It 
gives  the  statistical  mean  and  standard  deviation  of  the  document 
processing  time,  calculated  for  solved  documents  that  where  issued 
between  two  user  selected  dates.  This  information  is  based  on  the  time 
lapse  between  the  first  and  the  last  custody  transference  date-time 
recorded  in  the  Doc_Log  table  (document  history). 

Another  significant  feature  is  the  subject  retrieval  capability 
provided  by  the  Thesaurus.  Note  that  the  thesaurxis,  because  of  its 
relative  independence  from  the  Catalog  Euid  Control  databases,  may  be  used 
for  other  applications  in  the  same  environment.  The  interface  woiild  be  a 
table  like  the  table  Subject,  that  would  relate  thesaurus  terms  and  the 
other  system’s  primary  key.  In  a  school  environment,  for  instance,  could 
use  a  student  register  number  as  the  primary  key  to  retrieve  information 
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related  to  the  students  or  a  course  code  to  search  for  data  about 
courses . 

Reconmendations 

There  are  three  main  reconmendations  for  future  research.  The 
first  one  is  basic  to  permit  the  use  of  the  proposed  system’s  subject 
retrieval  feature.  The  second  is  desirable  to  improve  the  system 
security.  The  third  and  last  one  is  concerned  with  the  next  natural  step 
in  the  proposed  system  upgrading. 

Thesaurus  Building.  Defining  the  terms  that  will  constitute  the 
thesaurus  is  a  very  important  and  also  difficult  task.  We  recommend 
doing  a  initial  list  by  collecting  suggested  terms  already  used  in  the 
organizations  elected  to  have  the  syst«n. 

Passwords .  Forms  and  reports  in  the  proposed  system  use  a  master 
user  name  and  password.  The  modules  (forms)  were  organized  and 
partitioned  in  such  way  that  permit  password  modular  assignments  by 
operator.  Operator  responsibilities  should  be  well  defined  and  auxjesses 
must  be  granted  baised  on  these  obligations. 

Document  Entering  from  a  File.  A  natural  upgrading  is  exchanging 
dociments  in  computer  file  format.  In  this  situation,  an  alternative  way 
of  entering  document  data  in  the  system  would  be  a  program  to  parse  the 
received  document  file  and  to  insert  automatically  the  document  attribute 
values  into  the  database.  Oracle  has  a  utility  tool  referred  ais  Data 
Loader  (CS)L)  that  can  be  used  to  develop  an  automatic  docvment  entering 
module. 
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Conclusion 


Overall,  this  work  significantly  contributes  to  solving  a  basic  and 
important  problem  shared  for  numerous  Brazilian  Air  Force  organizations. 
The  proposed  system,  as  standard  software,  offers  many  possibilities,  as 
to  make  it  possible  to  query  the  databases  of  different  organizations  and 
to  exchange  documents  in  computer  file  format,  using  the  existing 
teleconmunication  networks.  It  represents  a  large  step  ahead  to 
accelerate  the  document  processing  and  to  improve  the  decision  making. 
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Appendix  A:  Script  File  for  Creation  of  Tables ,  Clusters .  and  Indexes 


Tbe  following  statements  were  used  in  the  script  file  CREATEJT.SQL 
to  create  the  database  in  the  Oracles 's  environment.  It  was  run  by 
typing  START  CREATE_T  from  inside  SQL»Plus  and  pressing  Enter.  The 
databEise  may  be  moved  or  replicated  using  this  file  or  using  a  export 
file  (Oracle  utility). 


CREATE  CLUSTER  C_ 

DOCUMENT 

(DRN 

NUMBER(8)); 

CREATE  TABLE 

DOCUMENT 

(KW 

NUMBER(8) 

NOT 

NULL, 

P__SC 

NUMBER(2) , 

P_OC 

NUMBER(2), 

P  NUMBER 

NUMBER(5) , 

P_YEAR 

NUMBER(2) , 

IDNR 

NUMBER(5) 

NOT 

NULL, 

IDOOMPL 

CHAR(13) 

NOT 

NULL, 

ORGNAME 

CHAR(20) 

NOT 

NULL, 

ISSUEDT 

DATE 

NOT 

NULL, 

TITLE 

CHAR(78) 

NOT 

NULL, 

DOCTYPE 

CHAR(7) 

NOT 

NULL, 

CLASSIF 

CHAR(l) 

NOT 

NULL, 

VALIDITY 

TIME 

NOT 

NULL, 

JOINSTS 

CHAR(l) 

NOT 

NULL, 

PROCSTS 

CHAR(l) 

NOT 

NULL, 

FX»MSTS 

CHAR(l) 

NOT 

NULL, 

HISTSTS 

CHAR(l) 

NOT 

NULL, 

ARCHSTS 

CHAR(l) 

NOT 

NULL) 

CLUSTER  CJXXXJMENT  (E«N); 


CREATE  INDEX  I_P_NUMBER 

OJ  DOCUMENT  (P_NUMBER  ASC) ; 

CREATE  INDEX  I_II»® 

ON  DOCUMENT  (IDNRASC); 

CREATE  INDEX  IJDRGNAME 

ON  DOCUMENT  (ORGNAME); 

CREATE  TABLE  REFERENCE 

(ORN  NUMBER(8)  NOT  NULL, 
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REFER 

CHAR(20) 

NOT 

NULL) 

CUBTER  CJDOCUMENT  (E«N); 

CREATE  TABLE 

ANNEX 

(DRN 

NUMBER(8) 

NOT 

NULL, 

ANNEX 

CRAR(20) 

NOT 

NULL) 

CLUSTER  C_DO(XJMENT  (DRN); 

CREATE  TABLE 

JOIN 

(MAIN 

NUMBER(8) 

NOT 

NULL, 

JOINED 

NUMBER(8) 

NOT 

NULL) 

CLUSTER  C_DOCUMENT  (MAIN) 

CREATE  TABLE 

MICROFIIM 

(DRN 

NUMBER(8) 

NOT 

NULL, 

F_TYPE 

CHAR(l) 

NOT 

NULL, 

F  NO 

NUMBER(4) 

NOT 

NULL, 

FIRST 

NUMBER(5) 

NOT 

NULL, 

LAST 

NUMBER(5)) 

CLUSTER  C_DOCUMENT  (W?N); 

CREATE  TABLE 

DEPARTMENT 

(DEPOODE  CHAR(6) 

NOT 

NULL) 

CREATE  TABLE 

HOLDER 

(DRN 

NIMBER(8) 

NOT 

NULL, 

DEPOC»E  CHAR(6) 

NOT 

NULL, 

NAME 

CHAR(15)) 

CLUSTER  C_pOCUMENT  (DRN); 

CREATE  TABLE 

DOC_LOG 

(ORN 

NUMBER(8) 

NOT 

NULL, 

LDATE 

DATE 

NOT 

NULL, 

LTIME 

CRAR(5) 

NOT 

NULL, 

SEND  DEP  CHAR(6) 

NOT 

NULL, 

REC_DEP  CHAR(6) 

NOT 

NULL) 

CLUSTER  C_DOCUMERT  (TON); 


CREATE  VIEW  DOC_LOG_VIEW  AS 
SELECT 

TO_NUMBER  (TO_CHAR  (LDATE.’J’) 

11  SUBSTR(LTIME,1,2) 

11  SUBSTR(LTIME,4,2)) 

DRN,  LDATE,  LTIME,  SEND_DEP,  REC_DEP 
FROM  DOC_LOG; 

CREATE  TABL£  SUBJECT 

(I»N  NUMBER(8)  NOT  NULL, 

TERM  CHAR(25)  NOT  NULL) 

CLUSTER  CJXXXMENT  (WIN); 

CREATE  INDEX  SUBJECT  TERM 


JULIAN_D_T  , 
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SUBJECT 


(TERM  ASC) ; 


CREATE  CLUSTER  CTERM 

(TERM  CHAR(25)); 

CREATE  TABLE  TERMS 

(TERM  CHAR(25)  NOT  NULL, 

CLASSCD  CHAR(2)  NOT  NULL) 

CLUSTER  CTERM  (TERM); 

CREATE  TABLE  CLASSES 

(CLASSCD  CHAR(2)  NOT  NULL, 

CLASS  CHAR(20)  NOT  NULL) ; 

CREATE  TABLE  RELSHIPS 

(MAINTR  CHAR(25)  NOT  NULL, 

REL  CHAR(2)  NOT  NULL, 

SECTR  CHAR(25) 

CLUSTER  CTERM  (MAINTR); 

CREATE  TABLE  NOTES 

(TERM  CHAR(25)  NOT  NULL, 

NOTE  CHAR(60)  NOT  NULL) 

CLUSTER  CTERM  (TE»1); 


CREATE  TABLE  DOCJTYPE 

(DOCTYPE  CHAR(7)  NOT  NULL) ; 

CREATE  TABLE  CLASSIFICATICW 

(CLASSIF  CHAR(l)  NOT  NULL, 

CLASSIF_NAME  CHAR(12)  NOT  NULL); 

CREATE  TABLE  RELNAME 

(REL  CHAR(2)  NOT  NULL, 

RNAME  CHAR(8)  NOT  NULL); 

CREATE  TABLE  SB^'IUMBERS 

(LASTNUMBER  NUMBER(8), 

TABLENAME  CHAR( 30) ) ; 

CREATE  TABLE  TO_DELETE 

(DRN  NUMBER(8)); 


INSERT  INTO  CLASSIFICATION  VALUES  ( ’P’ , 'PUBLIC' ) ; 

INSERT  INTO  CLASSIFICATION  VALUES  ( 'R' , 'RESERVED' ) ; 
INSERT  INTO  CLASSIFICATION  VALUES  ( 'C' , 'OWJFTDENTIAL' ) ; 

INSERT  INTO  RELNAME  VALUES  ( 'BT' , 'BROADER' ) ; 

INSERT  INTO  RELNAME  VALUES  ( 'NT' , 'NARROWER' ) ; 
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INSERT  INTO  RELNAME  VALUES  ( ’RT’ , 'RELATED’ ) ; 

INSERT  INTO  RELNAME  VALUES  { 'US’ , 'USE' ) ; 

INSERT  INTO  RELNAME  VALUES  ( 'UF' , 'USED  PC*’ ) ; 

INSERT  INTO  DEPARTMENT  VALUES  { ’OOhWAN' ) ; 

INSERT  INTO  DEPARTMENT  VALUES  (  ’PROTOC’ ) ; 

INSERT  INTO  DEPARTMENT  VALUES  ( ' ARCHl ’ ) ; 

INSERT  INTO  DEPARTMENT  VAUJES  (’ARCH2’); 

INSERT  INTO  DEPARTMENT  VALUES  ('DEPl'); 

INSERT  INTO  DEPARTMENT  VALUES  (’DEP2’); 

INSERT  INTO  DEPARTMENT  VALUES  (’DEP3’); 

INSERT  INTO  DEPARTMENT  VALUES  ( ’DEP4’ ) ; 

INSERT  INTO  DEPARTMENT  VALUES  ( 'SECl' ) ; 

INSERT  INTO  DEPARTMENT  VALUES  ( ’SEC2’ ) ; 

INSERT  INTO  DOCJTYPE  VALUES  (’APRECIA’); 

INSERT  INTO  DCX:_TYPE  VALUES  ( ’DESPACTI’ ) ; 

INSERT  INTO  DOCJTYPE  VALUES  (’ENCAMIN’); 

INSERT  INTO  DOCJTYPE  VALUES  ( ’ESTIMAT’ ) ; 

INSERT  INTO  DOCJTYPE  VALUES  ( ’ INFO’ ) ; 

INSERT  INTO  DCCJTVTE  VALUES  (’OF’); 

INSERT  INTO  DOCJTYPE  VALUES  (’RELAT’); 

INSERT  INTO  D(X:_TYPE  VALUES  ( 'REL  ESP' ) ; 

INSERT  INTO  DOCJTYPE  VALUES  ( ’REL  PER’ ) ; 

INSERT  INTO  DOCJTYPE  VALUES  ( ’REQ’ ) ; 

INSERT  INTO  DOCJTYPE  VALUES  ( ’BOL’ ) ; 

INSERT  INTO  SBSNUMBERS  VALUES  ( 89100000, ’DOC_RECEIVED’ ) ; 
INSERT  INTO  SE(WIBERS  VALUES  (89200000, 'DOC JSENT’ ) ; 

INSERT  INTO  SEW^ERS  VALUES  (89100000, ’FRINT_PS_RECEIVED’ ) ; 
INSERT  INTO  SEIWIBERS  VALUES  (89200000, ’PRINT_PS_SENT’ ) ; 

INSERT  INTO  CLASSES  VALUES  ( ’00’ , ’BOOT’ ) ; 

INSERT  INTO  CLASSES  VALUES  ( ’01 ’ , ’C«GANIZATI(»J’ ) ; 

INSERT  INTO  TERMS  VALUES  ( ’RCXDT’ , ’00’ ) ; 

INSERT  INTO  TERMS  VALUES  ( ’C«GANIZATION  NAME’, ’01’); 

INSERT  INTO  RELSHIPS  VALUES  ( ’ROOT’ , ’BT’ ,  ”  ) ; 

INSERT  INTO  RELSHIPS  VALUES  ( ’C*GANIZATI(*’ , ’BT’ , ’ROOT’ ) ; 
INSERT  INTO  RELSHIPS  VALUES  ( ’ROOT’ , ’NT’ , ’ORGANIZATICW’ ) ; 

COMMIT 

EXIT 
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Appendix  B:  Screen  Templates 

The  symbols  and  conventions  used  on  the  screen  templates  are  listed 
in  Table  X. 

Screen  AO.  Main  Menu 


DOCUMENT  CONTROL  AND  RETRIEVAL  SYSTEM 

MAIN  MENU 

1  -  Register  Document 

2  -  Update  Database 

3  -  Consult  Databeuse 

4  -  Maintain  Thesaurus 


Type  your  choice:  C  Press  Enter  to  accept 

Ctrl-Z  to  exit 


AO 
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DOCUMENT  CONTROL  AND  RETRIEVAL  SYSTEM 


A1 


MAIN  MENU 

1  ♦  Register  Document 

2  -  Update  Database 

3  -  Consult  Database 

4  -  Maintain  Thesaurus 

Type  your  choice:  C  Press  Enter  to  accept 

Ctrl-Z  to  exit 


Register  Document 

1  -  Enter  Document 

2  -  Print  Processing 

Sheet 


Screen  All ,  Enter  Document 


I  I 

j  ENTER  DOCUMENT  Block  1  j 

i  I 

Automatic  DRN  C  DRN  99999999  Validity  DD-MC»J-Y\'  | 

I  ! 

Protocol  No  99-99/99999/99  Doc.  Type  CCCCCCC  Classif  C 

I  Doc.  Identif.  99999/CCCCCCCCCCCCC  Issue  Date  DD-MCW-YY 

I 

I  Organization  CCCOCCCCCCCCCCOOCCCCCOCOC  Status:  C  C  C  C  C 


Title 

Join  Proc 

Form  Hist  Arch 

(xccccoxxxxxxxxxxxxxxxxxxxxoxcccaxaxxxxxxxxxxxxxxxmxx^^ 

_ 

— 

Reference 

OOCCCCCOCCCCCCCCCCCC 

*f 

I* 

I 

Block  2  1 

1 

Annex 

COCCOOCCOOOCOOOCCCOC 

tt 

ft 

Block  3  ! 

All 

F7  query  FIO  insert/update 

Ctrl-Z  Menu 

1 
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Screen  A12.  Print  Process injg  Sheet 


1 - 

PRINT  PROCESSING  SHEET 

. 

Printing  Status: 

Received  Sent 

A  -  Leist  Document  Printed  99999999  99999999 

B  -  Last  Document  Entered  99999999  99999999 

_ t 

Options : 

1  -  Print  Received  Documents  from  A  to  B. 

2  -  Print  Sent  Documents  fran  A  to  B. 

3  -  Print  a  single  docianent,  given  the  DRN. 

Enter  your  choice:  C 

A12 

Enter  to  print  Ctrl-Z 

to  Menu 

Screen  A2 .  Update  Database 


DOCUMENT  OCWTROL  AND  RETRIEVAL  SYSTEM 


MAIN  MENU 

1  -  Register  Docunjent 

2  *  Update  Database 

3  -  Consult  Database 

4  -  Maintain  Thesaurus 


“1 


1  -  Generic  Update 

2  -  Change  Validity 

3  -  Doc.  Destruction 

4  -  Join  Documents 

5  -  Transfer  Custody 

6  -  Microfilm  Data 

7  -  Subject  Indexing 


Type  your  choice:  C 


Press  Enter  to  accept 
Ctrl-Z  to  exit 


A2 


1 
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Screen  A21-1 ,  Generic  Update 


Page  1  GENERIC  UPDATE  Block  1 

HW  99999999 

Protocol  No  99-99/99999/99  Doc.  Type  CCOCCCC  Class! f  C 

i 

Doc.  Identif.  99999/COCCCCCCCCCCC  Issue  Date  DD-MCW-YY 


Organization  CCCOCCCCCCCCCC(XCCCCCOCXX:  Status:  C  C  C  C  C 
Title  Join  Proc  Form  Hist  Arch 

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCOCCCCOOCOCCCCCCCCCOCCCCOCCCCCCCCCCCCCCCCCC 


Reference 

CCCCCCCCOCCCCCCCCCCC 

ft 

ft 

Block  2 

Annex 

OCCCCCCCCOCCCCCCOCCC 

ft 

Block  3 

|A21-1 

i 

F7  query  FIO  update  F6  del  PgDn  next  block/pg 

Ctrl-Z  Menu 

Screen 

1 - 

A21-2,  Generic  Update 

Page  2  GENERIC  UPDATE 


HOLDER  Block  4 

Department  CCCOCCC  Holder  Name  CCCCCCCCCCCCCCC 


HISTC»Y  Block  5 

Date  Time  Sender  Receiver 

DD-MON-YY  HH;MI  CCOCCCC  CCCCCOC 


PgUp  previous  block/pe^e  PgDn  next  block/page 

A21-2  F7  query  FIO  update/insert  Sh-F6  delete  Ctrl-Z  to  Menu 
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Screen  A22 


Validity 


j_  Change 


CHANGE  VALIDITY 


DRN  99999999  -  99  Validity  DD-MCW-YY 


1 

1 

II 

II 

•  I 

II 

n 

M 

1  A22 

F7  juery  FIO  update  Ctrl-Z  Menu 

Screen  A23.  Dcx;ument  De3ti~uction 


DOCUMENT  DESTRUCTION 

Reference  CCOOCCCCCCCCCCCCCCCCCCCCC 


I«N  99999999  -  99  Holder  (CCCCCC) 


Block  1 


Block  2 


Note:  Enter  a  reference  to  be  inserted  for  eeush  docvanent  processed 
A23  F7  query  Shift-F6  process  destruction  Ctrl-Z  Menu 


95 


Screen  A24,  Join  Dociments 


JOIN/SEPARATE  DOCUMENTS 

Main  Document  99999999  -  99  Joined  Docianent  99999999  -  99 


Screen  A25,  Transfer  Document 


DOCUMENT  OCKTROL  AND  RETRIEVAL  SYSTEM 


MAIN  MENU 


te  Data 


1  -  Register  DocuneB  Transfer  Cust 


;ijneB  I 

2  *  Update  Databasel  1  -  Department 

I  2  -  Holder  Name 

3  -  Consult  Databasl 


4  -  Maintain  Thesat^ 


Type  your  choice:  C  Press  Enter  to  accept 

Ctrl-Z  to  exit 
A25 


96 


Screen  A251 ,  Transfer  Custody  -  Department 


TRANSFER  CUSTODY  -  DEPARTMENT 


Sending  Receiving 

Department  Department  Date  Time  Document 

9999999  9999999  DD-MCW-YY  HH:MI  99999999-99 


A251 


F3  duplicate  field  FIO  create  records  Ctrl-Z  to  Menu 


Screen  A252 ,  Transfer  Custody  -  Holder  Name 


TRANSFER  CUSTODY  -  HOLDER  NAME 


Department  Holder  Name 

CCCCCCC  CCCCCCCCOCCOCCC 


Document 

99999999-99 


A252 


FIO  update  Ctrl-Z  Menu 
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i  A26  F7  query  FIO  insert/update  Shift-F6  delete  Ctrl-Z  Menu 

I 


Screen  A27,  Subject  Index! 


SUBJECT  INDEXING 

DRN  Ver  Thesaurus  Term  Class  Name 

99999999  -  99  CCOXXXXXXXXCCCCCCOCCCCCC  (XmXXXXXXCCCOCCCCC 
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Screen  A3.  Ctonsult  Database 


DOCUMENT  CONTROL  AND  RETRIEVAL  SYSTEM 


MAIN  MENU 


1  -  Register  Docun»ent 

2  -  Update  Database 


3  *  Consult  DatabsLse 


4  -  Maintain  Thesaurus 


Consult  Database 

1  -  Browse  by  Holder 

2  -  Look  Thes.  Terms 

3  -  Browse  by  Header 

4  -  Browse  by  Subject 

5  -  Retrieve  Document 


TjTDe  your  choice: 


Press  Enter  to  accept 
Ctrl-Z  to  exit 


Screen  A31 ,  Browse  Documents  By  Holder 


BROWSE  BY  HOLDER 


->  ->  ->  Date  of  -> 

Depart  Holder  N.  DRN  Prot#/yy  Doc  Ident.  Type  Register  Title 

CCCCCC  CCCCCCCC  99999999  99999  99  99999  CCCCC  CCCC  DD-MON-YY  CCCCCOCCCC 


IA31  F7  query  :V  variable  %  wildcard!*)  _  wildcard!?)  Ctrl-Z  Menu 
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Screen  A321 ,  Look  Up  Thesaurus  Classes 


LOOK 

U  P 

T  H  E  S  A 

U  R  U  S  -  CLASSES 

Class  Code 

CC 

If 

Name 

CCCOCCCCCCCCCCOCCCCC 

It 

A321  F7  query  :V  variable  %  wildceuxK*)  __  wildcard!?)  Ctrl-Z  Menu 


100 
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Screen  A324.  Look  Up  Terms  in  Sequential  Order 

LOOK  UP  THESAURUS-  TERMS  IN  SEQUENTIAL  ORDER 

Name  Class  Code 

CCCmXCCCCCCCCCCOCCCOCCC  OC  (OCCCCCCCCCCCXXCCCCCC) 


|A324  F7  query  :V  variable  %  wildcard(*)  _  wildcard!?)  Ctrl-Z  Menu 

I _ _ _ 

Screen  A33.  Browse  Documents  by  Heeiders 

! - 

i  BROWSE  BY  HEADERS 

I  ->  ->  ->  -> 

DRN  ID#  Issue  Org.  Type  C  Issue. Dt  Title 

99999999  CCCCC  CCCOCCCCCCCC  COCC  C  DD-MCW-YY  CCCCCCCCCCCCCOCCCCCCCCCCCC 


A33  F7  query  :V  variable  %  wildcard! »)  _  wildcard!?)  Ctrl-Z  Menu 
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BROWSE  BY  SUBJECT 


Page  1 

Term  to  browse  by  Other  terms  for  v^ich  the  document  is  indexed 

ccccxxcccccxxxxxxxxxxxxxx:  ((xcccccmxmxcccccc  cmxxxmxocccxxxxcc) 


I  A34-1  F7  query  Tab  next  page  Ctrl-Z  Menu 

Screen  A34-2.  Browse  Documents  By  Subject 

Page  2  BROWSE  BY  SUBJECT 

->  ->  ->  -> 

DRN  ID#  Issue  Organ  Type  C  Issue  Dt  Title 

99999999  99999  CCCCCCCCCCCC  CCCC  C  DD-MCW  CCCCCCCCCCCCCCCCCCCCCCCCCCCC 


A34-2  F7  query  Tab  previo\Js  page  Ctrl-Z  Menu 
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|Page  1  RETRIEVE  DOCUMENTS  (COMPLETE)  Block  1 


DRN  99999999  99  Validity  DD-MC»J-YY 

Protocol  No  99-99  /  99999  /  99  Doc.  Type  CCCCCC  Classif  C 

Doc.  Identif.  99999  /  CCCCCCCCCCCCC  Issue  Date  DD-MCW-YY 

Orgeuiization  CCCCCCCCCCCCCCCCCC  Status:  C  C  C  C  C 

I  Title  Join  Process  Form  Hist  Arch 

CCCCCCCCCOCCCCCCCCCCCCCCCCCCCCCCCCC«Xm}CCCCCCCCCCCCCCCCCCCCCCCCCCCC 


Subject  Index:  Block  2 

DRN  99999999  Term  CCCCCCCCCCCCCCCCCCCCCCCC  Class  CCCCCCCCCCCCCCCCCCC 


jA35-l  F6  help  F7  query  F5  browse  PgDn  see  more  Ctrl-Z  Menu 

I _ 

Screen  A35-2.  Retrieve  Documents 


I - 

Page  2  RETRIEVE  DOCUMENTS 

Reference:  CCCCCCCCCCCCCCCCCCCC  (999999999)  block  3 


Annex: 

CCCCCCCCCCCCCCCCCCCC  (999999999) 

block  4 

Join: 

Main  99999999  Joined  99999999 

block  5 

Microfilm: 

Type  C  #  9999  First  99999  Last  99999  (99999999) 

block  6 

Holder : 

Name  CCCOCOCOCCCCCCC  Dep  CCCCCC  DRN ( 99999999 ) 

block  7 

History: 

Date  DD-MON-YY  HH:MI  Send  CCCCCC  Rec  CCCCCC  MW 

ft  ff  tf  It 

(9999999) 

tf 

block  8 

tt  ft  91  ft 

ft  9t  tt  It 

tt  tt  tf  tt 

ft  ft  tt  tt 

tt  tt  tt  tt 

tt 

tt 

tt 

tt 

tt 

A35-2 

F7  query  PgUp  page  1  Ctrl-Z  Menu 
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Screen  A36.  Show  Statistics 


1 

SHOW  STATISTIC 

Enter  period:  from  DD-MON-YY  to  DD-MCW-YY 

1 

S 

_ 1 

Total  #  doc  999999 

Processing  time  in 

1 

days:  mesui  999  std  dev  9999  1 

Status : 

Processing 

Form  % 

Join 

% 

Ftiase  % 

paper  999999  999 

indep 

999999 

999 

processing  999999  999 

microfilm  999999  999 

main 

999999 

999 

waiting  999999  999 

destroyed  999999  999 

joined 

999999 

999 

solved  999999  999 

1 

History  % 

Archive  Sec  % 

\  normal  999999  999 

clEissified  999999  999 

i alteration  999999  999 

\ 

unclassified  999999  999 

Thesaurus : 

Classes  99  terms  999999  Scope 

Notes 

999999 

Relationships  999999  I 

1 

Indexed  doc:  #  999999 

%  999  #  of 

terms  by  indexed  doc :  avrg  99  std  999 | 

A36 


F5  calculate 


F7  clean  fields 


Ctrl-Z  Menu 
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Screen  A41 .  Maintain  Thesaurus  Classes 
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Screen  A43.  Maintain  Relationships 


MANTAIN  THESAURUS  -  RELATIONSHIPS 
Main  Term  Relation  Secondary  Term 

cxxcxxxxcmxxxxxxxxxxxxx:  cc  cccccccc  (xxxxxrcccccxxmxxxxxxxc 


A43 


Flo  insert/updt  Shift-F6  del  F5  look  up  terms  Ctrl-Z  Menu 


Screen  A44 ,  Print  Thesaurus  Terms 


MANTAIN  THESAURUS  -  PRINT  TERMS 


1  -  OJDER  BY  CLASS,  TERM 

2  -  CRDER  BY  TERM 

3  -  aUJER  BY  TERM  HIERARCHICAL  ASSOCIATION 

4  -  ORDER  BY  TERM,  GIVING  ALL  RELATICWSHIPS 


Choice  C 


A44  Enter  accept  choice  Ctrl-Z  Menu 
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Appendix  C:  Validation  and  Integrity  Rules 

Modules  AO,  A1 ,  A2.  A25.  A3.  A32.  A4  -  Menu  Tree 

Input  Condition:  Insertion ,  Update,  Deletion,  and  Quej^y. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Condition:  Value  of  Choice . 

.  According  the  value  of  the  choice  call  the  appropriated  module. 


Module  All  ^  Enter  Dociment 

Input  Condition:  Insertion . 

.  Verify  the  primary  key  of  the  table  Dociment:  HIK. 

.  Verify  the  primary  key  of  the  table  Iteference:  HW,  REFER. 

.  Verify  the  primary  key  of  the  table  Annex:  I®N,  ANNEX. 

.  Generate  automatically  the  IM4  for  a  received  document  v^ien  the  control 

field  "Automatic  IRN"  has  the  value  R. 

! 

.  Generate  automatically  the  WiN  for  a  sent  document  when  the  cixitrol 
field  "Automatic  MIN"  has  the  value  S. 

.  Permit  the  operator  to  type  the  H?N  that  will  be  used  for  the  insertion 
when  the  control  field  "Automatic  MW"  has  the  value  N  (none). 

.  Skip  the  DRN  field  vAien  the  control  field  is  set  to  generate  the  DRN 
automatically. 

.  Insert  automatically  a  validity  date  5  years  ahead  of  the  insertion 
date. 

.  Verify  if  exists  in  the  table  DocJType  the  value  entered  in  the 
dociment  type  field. 

.  Display  by  operator  request,  in  the  field  Dociment  Type,  the  values 
available  for  this  field. 

.  Verify  idiether  there  exists  in  the  table  QrgName  the  value  entered  in 
the  field  Organization. 

.  Verify  vAiether  there  exists  in  the  table  Classification  the  value 
entered  in  the  field  Cleissification. 
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.  Display  by  operator  request,  in  the  field  Doctinent  Classification,  the 
values  available  for  this  field. 

.  Insert  automatically  the  following  status  values: 

.  Join  =  I, 

.  Process  =  P, 

.  Form  =  P, 

.  History  =  N. 

.  Insert  automatically  the  Archive  status: 

.  If  document  classification  is  P  (public),  then  ARCHSTS  =  U; 

.  If  document  cleissification  is  R  or  C,  then  ARCHSTS  =  C. 

.  Insert  automatically  a  row  in  the  DOC_LOG  table  with  the  following 
values : 

.  I®N  =  the  document’s  DRN, 

.  LDATE  and  LTIME  =  date  and  time  of  registering, 

.  SEND_DEP  =  PROrrOC, 

.  REC_DEP  =  OOM^. 

.  Insert  automatically  a  row  in  the  HOLDER  table  with  the  following 
values: 

.  ffiN  =  docLment  IX2N, 

.  DEPOCDE  =  OOrWAN, 

.  NAME  =  NULL. 

Input  Condition:  Deletion. 

.  Do  not  permit  to  delete  a  dociment  (block  1). 

Input  Condition:  Update. 

.  Do  not  permit  to  change  the  MiN,  Validity,  and  all  status  fields. 

Input  Condition:  ftiery. 

.  Order  queries  by  WW  in  descendent  order. 

.  Permit  to  enter  a  query  condition  based  on  docvinent  table  valuer. 

.  Display  automatically,  when  the  operator  queries  the  docunent  block, 
the  Reference  and  Annex  rows  that  correspond  to  the  DRN  in  the  MIN  field. 
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Module  A12  -  Print  Processing  Sheet 
Input  Condition:  Pre-Form. 

.  Show  the  MW  of  the  last  docunent  entered  and  the  MW  of  the  last 
docLBient  printed,  either  received  and  sent. 

Input  Condition:  Value  of  Choice . 

.  When  Choice  is  1 ,  generate  the  processing  sheets  that  correspond  to  the 
received  dociments  that  have  a  DRN  higher  than  the  MW  of  the  laist 
document  printed,  emd  a  MW  smaller  or  equal  the  DRN  of  the  last  document 
entered . 

.  When  Choice  is  2,  generate  the  processing  sheets  that  correspond  to  the 
sent  documents  that  have  a  DRN  higher  them  the  DRN  of  the  last  document 
printed,  and  a  DRN  smaller  or  equal  the  DRN  of  the  last  document  entered. 

.  When  Choice  is  3,  ask  for  a  DRN  to  print  the  correspondent  processing 
sheet. 

.  In  either  choices  1,  2,  and  3,  also  direct  the  output  to  a  DOS  ASCII 
file. 

.  After  printing  choices  1  and  2,  update  the  table  Seqnunbers  (where  the 
last  DRN  entered  auid  printed  are  kept)  setting  the  last  E*W  printed  equal 
the  last  DRN  entered. 


Module  A21  -  Generic  Update 

Input  Condition:  Insertion. 

.  Do  not  permit  insertion  in  the  table  Docunent  (to  create  a  new 
document ) . 

.  Insertions  in  all  other  tables  must  use  the  same  DRN  of  table  Document. 
.  Verify  the  primary  key  of  the  table  Reference:  DRN,  REFER. 

.  Verify  the  primary  key  of  the  table  Annex:  MW,  ANNEX. 

.  Verify  the  primary  key  of  the  table  Holder:  MW. 

.  Verify  the  primary  key  of  the  table  Doc_Log:  MW,  LDATE,  SEND_DEP. 

.  Rules  for  Holder  and  Document  Log  tables  are  the  same  of  thoue  on 
update  input  condition. 

Input  Condition:  Update. 

.  Do  not  permit  to  update  the  MW  in  the  table  Document. 
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.  Verify  in  the  table  Doc_Type  the  existence  of  the  value  entered  in  the 
field  Docvjnent  Type. 

.  Verify  in  the  table  OrgName  the  existence  of  the  value  entered  in  the 
field  Organization. 

.  Verify  in  the  table  Classification  the  existence  of  the  value  entexed 
in  the  field  Classification. 

.  If  the  document  is  Joined  or  Destroyed,  do  not  permit  to  access  the 
Holder  and  the  Document  Log  tables. 

.  Update  the  table  Holder  automatically  vdien  a  row  is  inserted,  updated, 
or  deleted  in  the  table  Doc_Log  (Historic).  Set  the  field  Holder  Name 
equal  null  and  the  field  Holder  Department  equal  the  latest  department 
that  received  the  document. 

.  Set  the  document  history  status  equal  "A”  (alteration)  if  there  exists 
a  row  in  the  table  Doc_Log  in  which  the  sending  department  is  different 
from  the  receiving  department  in  the  previous  row.  Otherwise,  set  the 
document  history  status  equal  "N”  (normal).  Example:  assime  there  are 
two  rows  in  the  Doc_Log  table,  ordered  by  I®N,  Date,  and  Time,  in 
ascendent  order,  with  these  values: 


DRN 

Date 

Time 

Send_Dep 

RecJDep 

99999999 

DATEl 

TIMEl 

DEPl 

DEP2 

SAME  I«N 

DATE2 

TIME2 

DEP3 

DEP4 

Tbe  uuiderlined  departments 

should  be  the 

same .  As  they 

are  not  the 

set  the  document  history  status  equal  A. 

Input  Condition:  Deletion. 

.  If  the  document  to  be  deleted  is  a  Main  document,  delete  also  all 
corresponding  joined  documents  in  the  join  table. 

.  Each  document  deleted  from  the  table  document,  has  to  be  deleted  also 
from  the  following  tables: 

.  Reference 
.  Annex 
.  Doc_Log 
.  Holder 
.  Join 
.  Microfilm 
.  Subject 

Input  Condition:  Query. 

.  Order  queries  by  DRN  in  descendent  order. 
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.  Permit  to  enter  a  query  with  conditions  based  only  on  colvmns  of  table 
Dociment.  Query  all  other  tables  by  the  ESN  entered  in  the  table 
Document. 

.  Display  automatically,  vhen  the  operator  queries  the  docixnent  block, 
the  Reference  and  Annex  rcws  that  correspond  to  the  document. 

.  If  the  document  is  Joined  or  Destroyed,  do  not  permit  to  access  the 
Holder  and  the  Docunent  Log  tables. 

.  Display  automatically,  when  the  operator  turns  to  the  second  petge  of 
the  form,  the  Holder  and  Doc_Log  rows  that  corresponds  to  the  I®N  entered 
on  table  Document. 

.  Display  again  the  rows  of  tables  Doc_Log  and  Holder  after  an  updating, 
deletion  or  insertion  in  table  Doc_LiOg. 


Module  A22  ^  Change  Validity 

Input  Condition:  Insertion  and  Deletion . 

.  Do  not  permit  these  operations  in  the  module. 
Input  Condition:  Update. 

.  Before  updating,  test  the  Verifier  correctness. 


Form  A23  ^  Process  Document  Destruction 

Input  Condition:  Insertion  £0x1  Update. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Condition:  Process  Document  Destruction. 

.  Test  the  Verifier (s)  correctness. 

.  If  the  document  is  a  Main  docunent  in  a  Join  relationship  process  also 
the  docunent  that  are  joined  to  it. 

.  Delete  the  docunent(s)  from  the  tables: 

.  Reference 
.  Annex 
.  Doc_Log 
.  Holder 
.  Join 
.  Microfilm 
.  Subject 
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.  Set  the  status  of  each  docunent  equal  "D"  ( table  Docunent ) . 

.  Insert  a  reference  in  the  Reference  table  for  each  docunent  that  was 
processed. 

Module  A24  ^  Join  Documents 

Input  Condition:  Update. 

.  Do  not  permit  this  operation  in  the  module. 

Input  Condi tion :  Insertion . 

.  Verify  the  primary  key  of  the  table  Join:  JOINED. 

.  Verify  whether  document  exists  and  its  form  status  is  not  destroyed. 

.  Verify  vdiether  the  Main  document  is  already  a  Joined  docunent. 

.  Verify  vhether  the  Joined  document  is  already  in  the  table. 

.  Verify  vdiether  the  Main  and  Joined  documents  are  the  same. 

.  Test  Verifiers  correctness. 

.  Set  the  join  status  of  the  Main  document  equal  "M",  Emd  of  the  Joined 
document  equal  " J" . 

.  Delete  the  Historic  emd  Holder  of  the  joined  docunent. 

Input  Condition:  Deletion . 

.  Set  the  join  status  of  the  Joined  docunent  equal  "I". 

.  Set  the  joined  document  holder  depjartroent  and  holder  name  equal  to 
those  of  the  Main  document. 

.  Insert  in  the  joined  docunent  log  (History)  the  latest  transference  in 
the  main  docunent  history. 

.  Set  the  join  status  of  the  Main  docunent  equal  "I",  only  if  there  is 
not  any  other  document  joined  to  it. 

Module  A251  -  Transfer  Custody  Department 
Input  Condition:  Update  and  Deletion. 

.  Do  not  permit  these  operations  in  this  form. 

Input  Condition:  Insertion . 
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.  Verify  the  prinarj'  key  of  the  table  Doc_Log:  WIN,  LDATE,  SEND_DEP. 

.  Verify  the  existence  of  the  sending  emd  receiving  departments. 

.  Verify  the  existence  of  the  document  in  the  DocJLog  table. 

.  Verify  whether  the  docvment  is  joined. 

.  Verify  vrfiether  the  document  was  destroyed. 

.  Test  Verifier  correctness. 

.  Update  the  table  Holder.  Set  the  field  Holder  Name  equal  niill  and  the 
field  Holder  Department  equal  the  receiving  department  of  the  latest  row. 


.  Set  the  document  history  status  equal  ”A"  (alteration)  if  there  exists 
a  transference  of  the  document  in  which  the  sending  department  is 
different  from  the  receiving  department  in  the  previous  row.  Otherwise, 
set  the  document  history  status  equal  "N"  (normal).  Example:  assume 
there  are  two  rows  in  the  Doc_Log  table,  ordered  by  1»N,  Date,  and  Time, 
in  ascendent  order,  with  these  values: 


Date 

Time 

Send  Dep 

Rec  Dep 

99999999 

DATEl 

TIMEl 

DEPl 

DEP2 

SAME  MW 

DATE2 

TIME2 

DEP3 

DEP4 

The  underlined  departments  should  be  the  same.  As  they  are  not  the  same, 
set  the  docimient  history  status  equad  A. 


Module  A252  Transfer  Custody  Holder  Name 

Input  Condition:  Insertion  and  Deletion. 

.  Verify  the  primary  key  of  the  table  Holder:  DRN. 
.  Do  not  permit  these  operations  in  the  modvile. 

Input  Condi tiOTi:  Update. 

.  Update  only  the  Holder  Name. 

.  Test  the  EKN  Verifier  before  updating. 

Input  CcMidition:  Query. 

.  Query  by  all  colimms  of  table  Holder. 
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Module  A26  -  Update  Microfilm  Data 


Input  Condi ticMi:  Insertion. 

.  Verify  the  primeury  key  of  the  table  Microfilm:  MiN,  FJTYPE,  F_NO, 
FIRST. 

.  Verify  whether  the  docnxnent  exists  in  table  Document. 

.  Test  Verifier  correctness. 

.  Change  Form  status  to  M  (microfilmed). 

Input  Condition:  Update  and  Deletion. 

.  Test  Verifier  Correctness. 

.  Do  not  permit  to  update  the  DRN  field. 

.  Update  Form  status  to  P  (paper)  when  the  last  row  of  a  dociment  is 
deleted  from  the  table  Microfilm. 

Module  A27  ^  Sub.iect  Indexing 

Input  Condition:  Insertion  and  Update. 

.  Verify  the  primary  key  of  the  table  Subject:  MW,  TERM. 

.  Verify  the  document  existence  in  the  table  document. 

.  Test  the  Verifier  correctness. 

Input  Condition:  Deletion. 

.  Test  the  Verifier  correctness. 

Input  Condi ticm:  Query. 

.  Display  the  class  of  each  term. 

.  Query  by  all  columns  of  table  Subject. 

.  Permit  a  direct  access  to  Look  up  Terms  e  Relationships  form. 

.  Permit  to  copy  a  term  from  the  LocA  up  Terms  form  and  peiste  it  cxi  the 
Subject  Indexing  form. 
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Module  A31  -  Browse  by  Holder 

Input  CcMidition:  Insertion.  Update ,  and  Deletion. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Ciondition:  Query. 

.  Query  by  the  holder  depeirtinent ,  holder  name,  and  IH94. 

.  Order  queries  by  department,  holder  name,  and  MW  in  descendent  order. 

.  For  eeuzsh  dociment  retrieved  by  the  query,  show  the  corresponding 
colxjnns  of  table  Docunent. 

Module  A321  ^  Look  up  Thesaurus  Classes 

Input  Condition:  Insertion.  Update,  and  Deletion. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Condition:  Query. 

.  Order  queries  by  CLASS,  CLASSCD  (claiss  code). 

Module  A322  -  Look  up  Thesaurus  Terms  and  Relations 

Input  Condition:  Insertion.  Update,  and  Deletion. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Condition:  Query. 

.  Query  by  term  and  class. 

.  Order  queries  by  CLASSCD  (class  code),  TERM. 

.  For  each  term  retrieved  by  the  query,  show  the  existing  scope  note, 
from  the  table  Notes,  auxl  the  existing  relationships  and  corresponding 
terms,  from  the  table  Relshipe. 

.  Permit  to  copy  a  term  into  a  memory  variable  to  be  possible  to  paste 
the  term  in  a  calling  module. 
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Module  A323  ^  Look  up  Thesaurus  Terms  within  Classes 

Input  Condition:  Insertion.  Update,  and  Deletion. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Condition:  Query. 

.  Query  by  term  and  class. 

.  Order  queries  by  CLASSCDi  TERM. 

Module  A324  Look  up  Thesaurus  Terms  Sequentially 

Input  Condition:  Insertion.  Update,  and  Deletion. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Condition:  Query. 

.  Query  by  term. 

.  Order  queries  by  TEEW. 

.  For  each  term  retrieved,  show  the  corresponding  class  name,  from  the 
table  Claisses. 

Module  A33  ^  Browse  by  Header 

Input  Condition:  Insertion.  Update,  and  Deletion. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Condition:  Query. 

.  Query  by  DRN,  document  identification  number,  issuing  organization, 
issued  date,  docunent  type,  classification,  and  document  title. 

.  Order  queries  by  DRN  in  descendent  order. 

Module  A34  Browse  by  Subject 

Input  Condition:  Insertion.  Update,  and  Deletion. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Condition:  Query. 

.  Query  by  term,  from  the  subject  indexing  table. 
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.  For  each  docunent  retrieved,  show  other  terms  under  tdiich  the  document 
is  also  indexed. 

.  For  each  docunent  retrieved,  show  from  the  table  Docunent  its 
corresponding  IMI,  docum^it  identification  nisnber,  issuing  organization, 
issued  date,  docunent  type,  classification,  and  docunent  title. 

.  Order  queries  by  term  and  I®N  in  descendant  order. 

Module  A35  Retrieve  Documents 

Input  Condition:  Insertion ,  Update,  smd  Deletion. 

.  Do  not  permit  these  operations  in  the  module. 

Input  Condition:  Query. 

.  Query  by  all  attributes  a  document  may  have,  from  all  tables. 

.  Order  queries  by  MW  in  descendant  order. 

Module  A36  -  Show  Statistics 

Input  Condition:  Insertion.  Update,  and  Deletion . 

.  Do  not  permit  these  operations  in  the  modiile. 

Input  Condition:  Query. 

.  Query  tables  by  a  period  of  time. 

.  Calculate  statistics  from  database  tables. 

Module  A41  Maintain  Thesaurus  Classes 

A  class  is  also  a  thesaurus  term.  We  may  think  in  a  class  as  a 
implicit  one  level  hierarchical  relationship  between  a  term  (the  class 
name)  and  other  terms  v4iich  eu^  subordinated  to  it.  Explicit 
hierarchical  relationships  are  expressed  by  the  hierarchical 
relationship.  All  terms  that  have  explicit  hierarchical  relationships 
have  to  be  descendants  of  the  terra  BOOT,  vdiich  is  the  root  of  the 
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explicit  hierarchical  relationship  tree.  When  a  class  is  created  it  is 
also  created  a  hierarchical  relationship  ccxmecting  the  cleiss  name 
(actually  the  term  which  corresponds  to  a  class  name)  to  the  root  of  the 
hierarchical  tree.  All  hierarchical  relationships  subtrees  of  this  class 
that  will  be  further  created  will  be  connected  to  the  hierarchical  tree 
trough  the  claiss  name. 

Because  of  these  characteristics,  some  operations  in  the  table 
Class  have  consequences  in  the  tables  Terms,  Notes,  Subject,  and 
Relationships. 


Input  (Condition:  Insertion . 

.  Verify  the  primary  key  of  table  Classes:  CLASSCD. 

.  Verify  the  uniqueness  of  the  class  name  in  the  table  Classes. 

.  Verify  the  uniqueness  of  the  class  name  in  the  table  Terms. 

.  Insert  automatically  in  the  table  TERMS  a  term  corresponding  to  the 
class  being  created  (vhich  will  be  referred  as  the  "class-term"  like  the 
example  below: 

Table  Claisses:  Class  Name  =  'J(»S’,  Class  Ckxle  =  ’04’ 

Table  Terms:  Term  Name  =  ’JC®S’,  Class  Code  =  ’04’ 

.  Insert  automatically  in  the  table  Notes  a  note  equal  "CLASS" 
corresponding  to  the  class- term. 

.  Insert  automatically  in  the  table  Relships  a  hierauTchical  relationship 
(and  the  correspondent  reciprocal  entry)  where  the  main  term  is  the 
clMs-term  that  is  being  inserted,  the  relationship  is  broader  term,  and 
the  secorxlary  term  is  "BOOT" . 

Input  Condition:  Update. 

.  Verify  the  primary  key  of  table  Classes:  ClASSCD. 

.  Verify  the  uniqueness  of  the  class  name  in  the  table  Classes. 

.  Verify  the  uniqueness  of  the  class  name  in  the  table  Terms. 

.  Do  not  permit  updating  of  classes  00  amd  01.  Give  a  message  saying  they 
are  owned  by  the  system. 
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.  l^pdate  in  the  table  Subject  the  corresponding  terms. 

.  Update  in  the  table  Terms  the  corresponding  term. 

.  When  the  class  code  vias  updated,  update  in  table  Terms  the  class  code 
of  all  terms  that  pertain  to  the  class  being  update  . 

.  Update  in  table  Notes  the  corresponding  terms. 

.  Update  in  table  Relshi|3s  the  rows  that  have  either  the  main  term  or  the 
secondary  term  equal  the  class  name. 

Input  Condition:  Deletion. 

.  Do  not  permit  deleting  the  classes  00  and  01.  Give  a  messaige  saying 
they  are  owned  by  the  system. 

.  Delete  in  the  table  Subject  all  rows  that  have  the  colixnn  term  equal 
the  class  being  deleted. 

.  Delete  in  the  table  Relships  the  rows  that  have  either  the  main  term  or 
the  secondary  term  equal  a  term  pertaining  to  the  class  being  deleted. 

.  Delete  in  the  table  Notes  the  rows  that  have  the  column  term  eqtial  a 
term  pertaining  to  the  class  being  deleted. 

.  Delete  in  the  table  Terms  the  rows  that  have  the  column  cleiss  code 
equal  the  class  code  of  the  class  being  deleted. 

Input  Condition:  Query. 

.  Order  by  class  code. 

.  Query  by  class  code  and  class  name. 

Module  A42  -  Maintain  Thesaurus  Terms 
Input  Condition:  Insertion. 

.  Verify  the  primary  key  of  the  table  Terms:  TERM. 

.  Verify  the  primary  key  of  the  table  Notes:  TERM,  NOTE. 

Input  Condition:  Update. 

.  Do  not  permit  updating  class-terms. 

.  Update  in  the  table  Subject  the  corresponding  terms. 

.  Update  in  table  Notes  the  corresponding  terms. 
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.  Update  in  table  Relshipe  the  rows  that  have  either  the  main  term  or  the 
secondary  term  equal  the  class  name. 

Input  Condition:  Deletion . 

.  Delete  in  the  table  Subject  all  rows  that  have  the  colimin  term  equal 
the  term  being  deleted. 

.  If  there  exist  hierarchical  relationships  in  the  table  Relships 
involving  the  term  being  deleted,  disconnect  the  deleting  term  from  the 
hierarchical  tree. 

.  Delete  in  the  table  Relships  the  rows  that  have  either  the  main  term  or 
the  secondary  term  equal  the  term  being  deleted. 

.  Delete  in  the  table  Notes  the  rows  that  have  the  column  term  equal  the 
term  being  deleted. 

Input  Condition:  Query. 

.  Order  queries  by  TERM  ( table  Terms ) . 

.  Display  for  each  term  shown  in  the  table  Terms  the  corresponding  class 
name. 

.  Display  for  each  term  shown  in  the  table  Terms  the  corresponding  scope 
notes . 

.  When  querying  the  table  Scope  Notes,  display  for  each  scope  note  the 
correspondent  terms. 

.  Permit  to  copy  and  paste  between  blocks  and  to  and  from  other  forms. 


Module  A43  -  Maintain  Thesaurus  Relationships 
The  Hierarchical  Tree. 

.  The  hierarchical  relationships  form  a  hierarchical  tree.  The  root  of 
this  tree  is  the  term  "root",  vAiich  is  the  single  term  of  a  cleiss  created 
by  the  system,  also  named  "root",  vAiich  has  the  class  code  "00".  The 
nodes  at  the  first  level  of  this  tree  are  composed  of  class  names. 
Therefore,  eac^  class  is  a  child  of  the  root.  These  relationships  are 
maintained  automatically  when  a  class  is  created,  updated  or  deleted. 

All  terms  that  have  hierarchical  relationships  are  descendants  of  their 
classes . 

Input  Condition:  Insertion. 

.  Do  not  permit  the  operator  to  insert  relationships  having  "root"  as  the 
main  term  or  secondary  term. 
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.  Verify  the  prijnary  key  of  the  table  Relships:  main  term,  relationship, 
and  se<x>ndary  term. 

.  Verify  the  term  existence  in  the  table  Terms. 

.  Verify  the  uniqueness  of  a  main  term  in  a  "use"  relationship,  and  its 
reciprocal  entry  secondary  term  in  a  "used  for"  relationship. 

.  Verify  uniqueness  of  MAINTR,  ’BT’  (broader  term)  relationship  and  its 
reciprocal  entry  SECTR,  ’NT’  (narrower  term). 

.  Do  not  create  hierarchical  relationships  with  terms  that  have  a  "use" 
relationship. 

.  Do  not  permit  a  term  to  have  both  the  "use"  and  the  "used  for"  synonym 
relationships . 

.  Verify  that  both  terms  in  a  "broader  term"  or  in  a  "narrower  term" 
relationship  pertain  to  the  same  claiss. 

.  Connect  automatically  to  the  claiss  in  the  hierarchical  relationship 
tree,  hierarchical  relationships  between  terms  that  are  disconnected  from 
the  tree.  As  an  example  suppose  "microcomputer"  amd  "keyboard"  are  terms 
pertaining  to  the  class  "computer"  and  that  no  previous  hierarchical 
relationships  were  created  involving  these  two  terms.  The  insertion  of 
the  relationship 

<microcomputer ,  NT,  keyboard> 

will  generate  automatically  the  following  relationships: 

<keyboard,  BT,  microcomputer > ,  which  is  the  reciprocal  entry, 
<microcomputer ,  BT,  comp)uter>  to  connect  the  previous  relation 

to  the  hierarchical  tree, 

<computer,  NT,  microcomputer>  which  is  the  reciprocal  entry. 

.  Insert  the  reciprocal  of  the  hierarchical  (broader /narrower) 
relationship  automatically. 

.  Insert  the  reciprocal  of  the  associative  (related)  relationship 
automatically. 

.  Insert  the  reciprocal  of  the  synonym  (use/used  for)  relationship 
automatically. 

.  Create  euitomatically  a  hierarchical  relationship  between  a  term  and  its 
class  name  when  the  broader  term,  in  a  hierarchical  relationship  being 
inserted,  is  disconnected  from  the  hierarchical  tree  in  the  table 
RELSHIPS. 

Input  Condition:  Update. 
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.  Permit  to  update  only  the  main  term. 

.  Do  not  permit  the  operator  to  update  relationships  having  "root"  as  the 
main  or  secondary  term. 

.  Verify  that  both  terms  in  a  "broader  term"  or  in  a  "narrower  term" 
relationship  pertain  to  the  same  claiss. 

.  Update  the  reciprocal  of  the  hierarchical  (broader/narrower) 
relationship  automatically. 

.  Update  the  reciprocal  of  the  associative  (related)  relationship 
automatical ly . 

.  Update  the  reciprocal  of  the  synonym  (use/used  for)  relationship 
automatically. 

Input  Corxiition:  Deletion. 

.  Do  not  permit  the  operator  to  delete  relationships  having  "root"  as  the 
main  or  secondary  term. 

.  Delete  the  reciprocal  of  the  hierarchical  (broader/narrower) 
relationship  automatically. 

.  Delete  the  reciprocal  of  the  associative  (related)  relationship 
autcmiatically. 

.  Delete  the  reciprocal  of  the  synonym  (use/used  for)  relationship 
automatically. 

.  Before  deleting  a  hierarchical  relationship  disconnect  the  deleting 
node  (the  relationship  and  its  reciprocal  entry)  from  the  hierarchical 
tree. 


Input  Condition:  Query. 

.  Order  queries  by  MAINTO,  REL,  SECTR. 

.  Display  the  relaticmship  name  corresponding  to  the  relationship  code 
(REL). 

.  Permit  a  direct  access  to  Look  up  Terms  e  Relationships  form. 

.  Permit  to  cop>'  a  term  from  the  Look  up  Terms  form  emd  paste  it  on  the 
form. 
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Module  A44  ^  Print  'n^esaurus  Terms 

Input  Condition:  Insertion.  Update  and  Deletion. 

.  Do  not  permit  these  operations  in  this  form. 

Input  Condition:  Value  of  Choice . 

.  According  the  value  of  choice  ( 1 ,  2 ,  3  or  4 )  generate  the  following 
reports : 

Report  A44_l:  Order  by  Class,  Term. 

Select  all  terms  and  their  class  codes  from  the  table  Term  and  list 
them  ordered  by  Class  and  Term.  Select  from  table  Classes  the 
correspxjnding  Class  Name.  Print  the  class  only  vihen  the  cIeiss  changes 
and  at  the  beginning  of  a  new  page. 

Report  A44_2:  Order  by  Term. 

Select  all  terms  and  their  class  codes  from  table  Term  and  list 
them  ordered  by  Term.  Select  from  table  Classes  the  corresponding  Class 
Name.  Print  the  class  only  vhen  the  class  cheuiges  Eind  at  the  beginning 
of  a  new  page. 

Report  A44_3:  Order  by  Term  Hierarchical  Association. 

Select  all  terms  from  the  table  Relships  by  traversing  the 
hierarchical  tree  in  "preorder".  Print  terms  and  their  corresponding 
level  in  the  hierarchical  tree.  Indent  each  term  3  times  its  own  level. 

Report  A44_4:  Order  by  Term,  Giving  all  Relationships. 

Select  all  terms  from  the  table  Terms  8uxi  for  each  term  select: 

-  the  corresponding  scope  notes  from  the  table  Notes, 

-  The  corresponding  relationship  codes  and  secondary  terms  from  the  table 
Relships. 

-  The  relationship  name  corresponding  to  the  relationship  code  from  the 
table  RelNsune. 
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Appendix  D:  Selected  Triggers  from  the  INP  Files 


TTiis  appendix  briefly  explains  triggers ’s  usage  agid  lists  samples 
of  triggers  that  are  actually  used  in  the  proposed  system  forms.  The 
following  definitions  are  mainly  based  in  definitions  presented  in  the 
Oracle  manual  "SQL»Forms,  Designer's  Reference,  Version  2.0"  (Zussman, 
1987). 


gger  Execution  and  Conventions 

-  There  are  two  kinds  of  triggers: 

a.  SQL  statement,  b.  SQL*Forms  coomand 

-  A  trigger  is  composed  of  one  or  more  trigger  steps.  A  trigger 
succeeds  when  all  its  steps  succeeds. 

-  A  trigger  step  succeeds  if  it  acts  on  at  least  one  row  (SQL 
statement)  or  if  it  executes  properly  (SQL*Forms  coomand). 

-  Triggers  have  three  levels  or  scopes: 

1.  Form,  2.  Block,  3.  Field. 

-  When  a  same  type  of  trigger  is  defined  at  more  than  one  level,  the 
specific  overrides  the  general. 

-  The  prompt  '';Message  if  value  not  found  :"  is  used  in  a  INP  file  to 
introduce  the  oiessage  displayed  on  the  screen  ( if  any)  when  the 
trigger  step  fails. 

-  When  the  messaige  begins  with  a  star  means  that  the  normal  criteria 
for  success  and  failure  is  reversed.  Iberefore,  if  the  SQL 
statement  returns  any  row,  the  step  fails. 

-  Two  sentences  beginning  with  the  symbol  $  in  the  place  of  the 
referred  message  indicates  a  success  and  a  failure  label 
respectively.  If  the  actual  step  succeeds,  the  step  identified  by 
the  success  label  is  executed.  If  the  actual  step  fails,  the  step 
identified  by  the  failure  label  is  executed.  When  a  label  is  blank 
(there  is  only  the  symbol  $)  the  next  step  to  be  executed  follows  a 
sequential  ordering. 

-  The  prompt  ";Must  value  exist  Y/N  :"  states  the  necessity  of  a 
success  value  to  succeed  the  trigger  step.  Hie  normal  value  is 
(Y)e8.  When  the  answer  is  (N)o,  the  step  does  not  fail  v^en  no  row 
is  acted  on  (a  select  statement  select  no  row,  or  a  delete 
statement  deletes  no  row).  In  this  case,  the  trigger  may  fail  only 
because  of  syntax  errors. 

-  A  star  preceding  the  "Y"  or  "N"  referred  in  the  previous  item  means 
that  it  will  be  returned  success  if  the  step  causes  the  trigger  to 
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abort.  It  is  meaningful  only  if  the  value  corresponding  to  the 
prompt  "Must  value  exist  Y/N"  is  "Y". 

-  A  form  field  has  the  format  block. name" .  When  the  field  name  is 
unique  in  a  form,  the  block  name  is  no  needed 

(ex:  DOCUMENT. ESN"). 

-  SQL*Form  has  extended  the  SQL  "select"  statement.  It  added  to  it 
the  "into"  clause  that  copies  the  selected  value  into  a  form  field. 
After  a  "into"  clause  there  is  no  need  of  a  cooma  to  indicate  a 
form  field,  once  only  a  form  field  is  allowed  in  this  clause. 

-  A  one  row  and  one  colimm  dummy  table  named  DUAL  is  used  in  select 
statements  to  perform  form  field  validation. 


SQL*Forms  Commands 

There  are  four  SQL*Forms  commands: 

♦EXEMACEKD,  to  execute  macro  functions  eukI  simulate  operator  strokes 

-  #OOPY,  to  copy  values  between  form  fields  and/or  global  variables 
#ERASE,  to  release  memory  space  occupied  by  a  global  variable 

-  #HOST,  or  #OHOST,  to  execute  operating  system  commands. 

Macro  Function  Codes  Used  inside  a  SQL»Form  Exemacro  Conmand 

Macro  function  codes  are  used  inside  a  #EXH*1ACR0  command  to  perform 
the  desired  action.  The  most  used  macro  function  codes  in  this  work  are: 

-  CALL,  suspends  processing  of  the  current  form  and  displays  the  form 
specified.  When  terminated  with  and  Exit  code,  it  resunes  the 
original  form. 

-  CALL®?Y,  the  same  of  the  previous  except  that  only  queries  are 
permitted  in  the  called  form. 

-  ENT^Y,  enter  query. 

-  EXB^n',  execute  query. 

-  GOBLK  block,  moves  the  cursor  to  the  specified  block  in  the  current 
form. 

-  GOFLD  block. field,  moves  the  cursor  to  the  specified  field  in  the 
current  form. 

-  NOOP,  no  operation;  does  nothing  but  displays  the  message 
"Unrecognized  Command". 
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-  NXTBLK,  moves  the  cursor  to  the  first  field  of  the  next  block  in 
the  current  form.  If  the  cursor  was  in  the  last  block,  the  next 
block  is  the  first  block  in  the  form. 

-  PRVBLK,  previous  block. 

-  EXETOG  user_nained_trigger,  execute  a  user-named  trigger. 

-  CREREC,  create  record. 

-  DELREC,  delete  record. 

-  (XM^IT,  comnit. 

-  NEWFEM  form_name,  Replaces  the  current  form  in  memory  by  the  form 
specified. 


Form:  AO,  Menu  Tree 
Form  Level. 

Remark:  This  trigger  redefines  the  normal  exit  function  on  menu  tree 
modules.  It  calls  the  Main  Menu  idien  the  exit  function  key  is  pressed, 
whenever  there  not  exists  a  more  specific  Key-Exit  trigger. 

»*KEY-EXIT 

;SQL> 

#EXEMACBO  QOBLK  AO; 

;Mess8Lge  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Remark:  This  trigger  disables  the  Orau^le  menu  key  (the  user  must  use  the 
menu  screen ) . 

»»KEY-MENU 

;SQL> 

#EXEMACRO  NOOP; 

; Message  if  valtie  not  found  ; 

;Must  value  exist  Y/N  ; 

Y 


Remark:  This  trigger  disables  the  next  block  key  (the  user  must  use  the 
menu  screen ) . 

»»KEY-NXTBLK 
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:SQL> 

#EXEMAC3W  NOOP; 

;Nessa£e  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Block  AO. 


R«nark:  This  trigger  overwrites  the  form  level  trigger  key-exit.  Exiting 
from  the  Document  Control  system  must  be  made  from  the  Main  Menu. 
*KE\"-EXIT 
;SQL> 

#EXEMACRO  EXIT; 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Field  Choice . 

Remark:  This  trigger  branches  to  a  submenu  according  the  selected  choice. 
»»KEY-NXTFLD 
/ 

;SQL> 

SELECT  ’X’  FROM  DUAL 

WHERE  :A0. CHOICE  IN  ( ’ 1' , ’2’ , ’3’ , ’4’ ) 

/ 

; Message  if  value  not  found  : 

Invalid  choice.  Type  1,  2,  3,  or  4  and  Enter. 

;Must  value  exist  Y/N  : 

Y 

#EXEMACRO  CASE  AO. CHOICE  IS 


WHEN 

’1’ 

THEN 

QOBLK 

Al; 

WHEN 

•2’ 

THEN 

GOBLK 

A2; 

WHEN 

’3' 

THEN 

GCBLK 

A3; 

WHEN 

'4' 

THEN 

GOBUt 

A4; 

END  CASE; 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

Block  A2.  Field  Choice  ^ 

Remark:  Tliis  trigger  calls  other  forms  according  to  the  selected  choice. 

»*KEY-NXTFLD 

/ 

;SQL> 
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SELECT  'X'  FEWM  DUAL 

WHEEiE  :A2. CHOICE  IN  ( ’  1  ’ , '2' , ’3’ ,  M ’ , ’5‘ , '6' ,  ’ 7’ ) 

/ 

; Message  if  value  not  found  : 

Invalid  choice. 

;Must  value  exist  Y/N  : 

Y 

fEXEMACRO  CASE  A2. CHOICE  IS 

WHEN  ’1’  THEN  CALL  A21; 

WHEN  '2'  THEN  CALL  A22; 

WHEN  ’3’  TOEN  CALL  A23; 

WHEN  ’4’  THEN  CALL  A24; 

WHEN  ’5’  THEN  GOBLK  A25; 

WHEN  '6’  THEN  CALL  A26; 

WHEN  *7’  THEN  CALL  A27; 

END  CASE; 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Form  A1 1 ,  Enter  Document 
Block  Document. 

Remark:  This  trigger  executes  the  following  auctions: 

1 )  generates  the  IRN  automatically  according  the  operator  choice 
placed  in  the  field  Automat ic_Nunber: 

"R"  -  DRN  corresponding  to  a  received  document 
"S"  -  MiN  corresponding  to  a  sent  document 
Other  value  -  do  not  generate  the  DRN 

2)  Insert  a  validity  date  60  months  (5  years)  later  than  the 
register  date. 

3)  Insert  into  table  Doc_Log  and  Holder  values  corresponding  to  a 
custody  transference  from  the  Protocol  Section  to  the  Comnander. 

4)  Insert  into  the  Processing  Phase  Status  the  value  "P" 
(processing) . 

5)  Insert  into  the  Archive  Section  Status  the  value  "U"  if  the 
value  in  field  Classif  is  ”U",  otherwise  insert  a  "C". 

♦PRE-INSERT 

;SQL> 

SELECT  ’X’  FROM  DUAL 
WHERE  :AUT0MATIC_NUMBER  =  'R’ 

/»  Failure  label  TESTJS  */ 

/ 

;Message  if  value  not  found  : 

$REC  $TEST_S 

;Must  value  exist  Y/N  : 

N 

$REC 
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SELECT  t  F1«0M  SE^4UNBEE2S 
WHERE  TABLENAME  =  ' DOC_RECEIVED ’ 

PC*  UPDATE  OF  LASTNIWBER 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  ; 

Y 

UPDATE  SB^JUMBERS 

SET  LASTNUMBER  =  LASTNUMBER  +  1 

WHERE  TABLENAME  =  ’ DOCJiECEIVED ’ 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  ; 

Y 

SELECT  LASTNUMBER 
INTO  :DCCUMENT.DRN 
FROM  SEW^ERS 

WHERE  TABLENAME  =  ’DCC_RECEIVED’ 

/ 

; Message  if  value  not  found  : 

SVALIDITV’  $ 

;Must  value  exist  Y/N  : 

Y 

$TEST_S 

SELECT  *X’  FROM  dual 

WHERE  :AUT0MATIC_NUMBER  =  'S' 

/»  Failure  label  VALIDITY  */ 

/ 

;Message  if  value  not  found 

$SENT  SVALIDITY 

;Must  value  exist  Y/N  ; 

N 

$SENT 

SELECT  *  FROM  SB^-JUMBERS 
WHERE  TABLENAME  =  ’DCC_SENT’ 

PCK  UPDATE  OF  LASTNUMBER 

/ 

; Message  if  value  not  found  ; 

;Must  value  exist  Y/N  : 

Y 

UPDATE  SE^JUMBERS 

SET  LASTNUMBER  =  LASTNUMBER  +  1 

WHERE  TABLENAME  =  ’DOC_SENT’ 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  LASTNUMBER 
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INTO  :DOCUMENT.I«N 

FROM  SB^JIWBERS 

WHE32E  TABLENAME  =  ’DOCJSENT’ 

/ 

;Messa£e  if  value  not  found  : 

$VALIDITY  $ 

;Must  value  exist  Y/N  : 

Y 

SVALIDITY 

SELECT  ADD_MONTHS( SEDATE, 60) 

INTO  : DOCUMENT. VALIDITY 
FROM  DUAL 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

INSERT  INTO  D0C_L0G  VALUES 

( :DOCIJMENT.IM?N,SYSDATE,TO_CHAR(SYSDATE,  *HH24:MI’ ) ,  'PROTOC’  ,  ’OOhWAN'  ) 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

INSERT  INTO  HOLDER  (DRN.DEPOODE)  VALUES 
( ; DOCUMENT. MW,  ’OOhWAN’ ) 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  ’X’  FROM  DUAL 
WHERE  :DOClMENT.CLASSIF  =  ’P’ 

/*  Do  not  abort  trigger  when  step  fails 
Failure  label  CLASSIFIED  */ 

/ 

;Message  if  value  not  found  : 

$UNCLASSIFIED  $CLASSIFIED 
;Must  value  exist  Y/N  : 

N 

fUNCLASSIFIED 

SELECT  ’U’  INTO  : DOCUMENT. ARCHSTS 
FBOM  DUAL 

/*  Sucxsess  label  END  */ 

/ 

; Message  if  value  not  found  : 

$END  $ 

;Must  value  exist  Y/N  : 

Y 

SCLASSIFIED 

SELECT  ’C’  INTO  : DOCUMENT. ARCHSTS 
FROM  DUAL 
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;Messa£e  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Remark:  This  trigger  forbids  deletions  in  the  block 

^  FRE  “DELETTE 

;SQL> 

SELECT  'X’  FROM  DUAL 
/♦  Abort  trigger  vben  step  fails 
Reverse  return  code  */ 

; Message  if  value  not  found  : 

*It  is  not  permitted  to  delete  documents  in  this  module.  Use  GENERIC 
UPDATE. 

;Must  value  exist  Y/N  : 

Y 


Field  Automatic  Number. 

Remark:  This  trigger  validates  the  value  entered  in  the  field 
Automatic_Number  against  constant  values. 

**POST-CHANGE 

/ 

;SQL> 

SELECT  ’X’ 

FROM  DUAL  /*  dual  is  a  dummy  table  tf 

WHERE  :DOCIWENT.AUTOMATIC_NUMBER  IN  ( ’R’ , ’S' , ’N’ ) 

/ 

: Message  if  value  not  found  : 

Invalid  code  for  DRN  automatic  generation.  Enter  R,  S,  or  N. 
;Must  value  exist  Y/N  : 

Y 


Remark:  This  trigger  makes  the  cursor  to  skip  the  DRN  field  if  the 
operator  chose  automatic  DRN  generation  (values  R  or  S  entered  in  field 
Automatic_Nunber ) . 

»»KEY-NXTFLD 

/ 

;SQL> 

#EXEMACRO  CASE  AITTOMATICJJUMBER  IS 
WHEN  'N'  THEN  NXTFLD; 

WHEN  OTHERS  THEN  NXTFLD ; NXTFLD ; 

END  CASE; 

;Mess8ige  if  value  not  found  : 
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;Must  value  exist  Y/N  : 
Y 


Field  DocType. 

Remark:  This  trigger  validates  the  value  entered  in  field  DocType  against 
values  selected  from  the  table  DocJType. 

»*P08T-CHANGE 

/ 

;SQL> 

SELECT  DOCTYPE 
FROM  DOCJTYPE 

WHERE  DOCJTYPE. DOCTYPE  =  : DOCUMENT. DOCTYPE 
; Message  if  value  not  found  : 

Invalid  document  type.  Press  <F9>  to  see  a  field  list. 

;Must  value  exist  Y/N  : 

Y 


Field  OrgName. 

Remark:  This  trigger  validates  the  value  entered  in  field  OrgName  against 
values  selected  from  the  thesaurus  (table  Terms). 

**POST-CHANGE 

/ 

;SQL> 

SELECT  TERM 
FROM  TERMS 

WHERE  TERMS. TERM  =  : DOCUMENT. ORCWAME 
AND  TERMS. CLASSCD  =  ’01’ 

;Message  if  value  not  found  : 

Invalid  organization  name.  Enter  again. 

;Must  value  exist  Y/N  : 

Y 


Form  A12.  Print  Processing  Sheet ,  Block  A12 

Remark:  This  trigger  retrieves  from  table  SeqNimbers,  before  the  block  is 
displayed  on  the  screen,  the  values  of  the  last  received  and  sent 
docunents  printed  and  the  last  received  and  sent  document  entered  in  the 
system. 

♦PRE-BLOCK 

;SQL> 

SELECT  LASTNUMBER 
INTO  :P_RECEIVED 
FROM  SEQNUMBERS 

WHERE  SE^'IUMBERS.TABLENAME  =  ’ PRINT_PS_RECEIVED ’ 

/ 

;Message  if  value  not  found  : 
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;Must  value  exist  Y/N  : 

Y 

SELECT  LASTNUMBER 
INTO  :P_SENT 
FROM  SE^OIBERS 

WHERE  SEQNUMBERS.TABLENAME  =  ’ PRINT_PSJSENT ’ 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  LASTNUMBER 
INTO  :E_RECEIVED 
FROM  SE^JUMBERS 

WHERE  SEWJMBERS.TABLENAME  =  ’DOC_RECEIVED’ 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  LASTNUMBER 
INTO  :E_SENT 
FROM  SEQNUMBERS 

WHERE  SEQNUMBERS.TABLENAME  =  ’DOC_SENT’ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

Field  Choice . 

Remark:  This  trigger  calls  the  report  generator  corresponding  to  the  user 
choice.  After  the  report  generation  it  is  called  a  script  file  to  update 
the  table  SeqNumbers  with  the  last  doctanent  printed. 

»»KEY-NXTFLD 

/ 

;SQL> 

SELECT  ’X’  FROM  DUAL 
WHERE  :CHOICE  =  ’1’ 

/ 

; Message  if  value  not  found  : 

$REC  $SENT 

;Must  value  exist  Y/N  : 

N 

$REC 

#OHOST  'REPORT  A12_REC  -s’ 

/ 

;Mes8age  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 
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#a»ST  'SQLPLUS  eA12JREC.SQL’ 

/ 

;Message  if  value  not  found  : 

$£ND  $ 

;Must  value  exist  Y/N  : 

Y 

$SENT 

SELECT  ’X’  FROM  DUAL 
WHERE  rCHOICE  =  ’2’ 

/ 

; Message  if  value  not  found  : 

$START_REP(»T  $DRK 
;Must  value  exist  Y/N  : 

N 

$START_REPC*?T 

#C«OST  ’REPC*T  A12_SENT  -s’ 

/ 

;Mess2ige  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

#OHOST  'SQLPLUS  @A12_SENT.SQL’ 

/ 

; Message  if  value  not  found  : 

SEND  $ 

;Must  valxjie  exist  Y/N  : 

Y 

SDRN 

SELECT  ’X’  FROM  DUAL 
WHERE  :CHOICE  =  ’3’ 

/ 

; Message  if  value  not  found  : 

Invalid  choice.  Choose  1,  2,  or  3.  For  choice  3,  type  the  DRN  first. 
;Must  value  exist  Y/N  : 

Y 

tOHOST  ’REPC«T  A12_DRN  -s’ 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SEND 

#EXEMACBO  NEWFRM  A12; 

;Messa£e  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 
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Form  A21 ,  Generic  Update.  Block  Document 

Remark:  Tliis  trigger  makes  all  the  deletions  that  are  necessary  for 
eliminating  a  document  from  the  databeise.  Observe  the  tables  locking 
sequence.  Tables  are  unlocked  only  v^ien  the  deletion  is  comnitted. 
»FRE-DELETE 
;SQL> 

LOCK  TABLE  DOCUMENT  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  REFERENCE  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  ANNEX  IN  SHARE  UPDATE  MC©E 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  DOC_LOG  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  HOLDER  IN  SHARE  UPDATE  MC®E 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  JOIN  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  MICROFILM  IN  SHARE  UPDATE  MODE 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  SUBJECT  IN  SHARE  UPDATE  MCOE 

/ 

;Message  if  value  not  found  : 
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;Must  value  exist  Y/N  : 

Y 

DELETE  FROM  TOJDELETE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

INSERT  INTO  TO_DELETE  (I«N) 

SELECT  JOINED  FROM  JOIN 
WHERE  MAIN  =  : DOCUMENT . DRN 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  DOCUMENT 

WHERE  DRN  IN  (SELECT  DRN  FROM  TO_DELETE) 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

INSERT  INTO  TO_DELETE  (WIN)  VALUES  (: DOCUMENT. DRN) 

/ 

;Message  if  value  not  found  ; 

;Must  value  exist  Y/N  : 

Y 

DELETE  FROM  REFERENCE 

WHERE  WS  IN  (SELECT  E«N  FROM  TO_DELETE) 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  ANNEX 

WHERE  DRN  IN  (SELECT  DRN  FROM  TO_DELErE) 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  DOC_LOG 

WHERE  W?N  IN  (SELECT  WiN  FROM  TOJDELETE) 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  HOLDER 
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WHERE  IMiN  IN  (SELECT  MIN  FROM  TOJ)ELErE) 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FTiOM  JOIN 

WHERE  JOINED  IN  (SELECT  ORN  FROM  TO_DELETE) 

/ 

; Message  if  value  not  found  ; 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  MICROFILM 

WHERE  DRN  IN  (SELECT  DRN  FROM  TO_DELETE) 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  ; 

N 

DELETE  FROM  SUBJECT 

WHERE  DRN  IN  (SELECT  DRN  FROM  TO_DELETE) 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  TO_DELETE 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Remark:  This  trigger  queries  the  Reference  and  Annex  blocks 
automatically,  vdien  the  Block  document  is  queried. 
»KEY-ENT^Y 
;SQL> 

#EXEMACRO  ENTW; 

/ 

(Message  if  value  not  found  ; 

(Must  value  exist  Y/N  : 

*{ 

♦EXEMACRO  NXTB1K:(  EXE®IY( 

/ 

(Message  if  value  not  found  : 

(Must  value  exist  Y/N  : 

N 
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#EXEMACRO  NXTBLK;  EXB^Y; 

/ 

; Message  if  value  not  found  ; 

;Must  value  exist  Y/N  : 

N 

♦EXEMACRO  PRVBLK;  raVBLK; 

;Ness£Lge  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Form  A22 ,  Change  Validity,  Block  Docunent 

Remark:  This  trigger  tests  the  Verifier  value  entered.  If  there  is  an 
error  the  update  is  rolled  back. 

♦PRE-UPDATE 

;SQL> 

SELECT  ’X’  FROM  DUAL 

WHERE  iVERIFIER  =  TOjCHAR ( mod ( power ( :DRN,2) ,97) ) 

; Message  if  value  not  found  : 

Verifier  incorrect. 

;Must  value  exist  Y/N  : 

Y 


Form  A23 ,  Process  Document  Destruction.  Block  A23 

Remark:  This  trigger  makes  all  integrity  tests  and  operations  necessary 
to  process  a  document  that  has  been  destroyed. 

♦PRE-DELETE 

;SQL> 

SELECT  DRN  FROM  DOCUMENT 
WHERE  DRN  =  :DRN 
AND  PORMSTS  <>  ’D’ 

/ 

;Message  if  value  not  found  : 

Hiis  document  has  already  the  Form  Status  "(D)estroyed" . 

;M'jst  value  exist  Y/N  : 

Y 

SELECT  ’X’  FROM  DUAL 

WHERE  TO_CHAR( mod (power {: DRN, 2) ,97) )  =  :VERIFIER 

/ 

; Message  if  value  not  found  : 

Verifier  incorrect. 

;Must  value  exist  Y/N  : 

Y 

$LOCK_TABLES 

LOCK  TABLE  DOCUMENT  IN  SHARE  UPDATE  MODE 
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/ 

;Messa£e  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  REFERENCE  IN  SHARE  UPDATE  MC®E 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  ANNEX  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  DOC_LOG  IN  SHARE  UPDATE  MODE 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  HOLDER  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  JOIN  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  MICROFILM  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  SUBJECT  IN  SHARE  UPDATE  MC©E 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  t  FROM  TO_DELETE 

/ 

;Mes8age  if  value  not  found  : 

$NEXT1  $INSERT_INTO_TO_DELETE 
;Must  value  exist  Y/N  : 
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N 

$NEXT1 

DELETE  FROM  TO_DELETE 

/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

y 

$INSERT_INTO_TO_DELETE 

INSERT  INTO  TO_DELETE  (DRN)  VALUES  (:DRN) 

/ 

; Message  if  value  not  found  : 


;^feist  value  exist  Y/N  : 

Y 

SELECT  *  FROM  JOIN 
WHERE  MAIN  =  :DRN 
/ 

; Message  if  value  not  found  ; 
$NEXT2  $DELETE_REFERENCE 
;Must  value  exist  Y/N  : 

N 

$N'EXT2 

INSERT  INTO  TO_DELETE  (DRN) 
SELECT  JOINED  FROM  JOIN 
WHERE  MAIN  =  :mN 

/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

$DELETE_REFERENCE 
SELECT  *  FROM  REFERENCE 
WHERE  DRN  IN  (SELECT  MW  FROM  TO_DELETE) 
/ 

; Message  if  value  not  found  : 

$NEXT3  $DELETE_ANNEX 
(Must  value  exist  Y/N  ; 

N 

$NEXT3 

DELETE  FROM  REFEEffiNCE 

WHERE  DRN  IN  (SELECT  ESW  FROM  TO_DELETE) 

/ 

(Message  if  value  not  found  : 

(Must  value  exist  Y/N  : 

Y 

$DELETE_ANNEX 
SELECT  »  FROM  ANNEX 

WHERE  MW  IN  (SELECT  MW  FROM  TOJ)ELETE) 

/ 

(Message  if  value  not  found  : 
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$NEXT4  $DELETE_DOC_LOG 
;Must  value  exist  Y/N  : 

N 

$NEXT4 

DELETE  raOM  ANNEX 

WHERE  I®N  IN  (SELECT  EKN  FROM  TO_DELErE) 

/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

$DELErE_DOC_LOG 
SELECT  *  FRa4  DOC_LOG 

WHERE  DRN  IN  (SELECT  DRN  FROM  TO_DELETE) 

/ 

: Message  if  value  not  foxind  : 

$NEXT5  $DELETE_HOLDER 
;Must  value  exist  Y/N  : 

N 

$NEXT5 

DELETE  FROM  DOC_LOG 

WHERE  DRN  IN  (SELECT  DRN  FROM  TO_DELETE) 

/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

$DELETE_HOLDER 
SELECT  *  FROM  HOLDER 

WHERE  DRN  IN  (SELECT  E«N  FROM  TO_DELETE 
MINUS 

SELECT  DRN  FROM  TO_DELETE 
WHERE  DRN  =  :DRN) 

/ 

; Message  if  value  not  found  : 

$NEXT6  $DELETE_JOIN 
;Must  value  exist  Y/N  : 

N 

$NEXT6 

DELETE  FROM  HOLDER 

WHERE  DRN  IN  (SELECT  WW  FROM  TO_DELETE 
MINUS 

SELECT  DRN  FROM  TO_DELETE 
WHERE  MW  =  :MiN) 

/ 

;Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

$DELErE_JOIN 
SELECT  »  FROM  JOIN 

WHERE  JOINED  IN  (SELECT  HW  FROM  TO_DELETE) 
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/ 

;Message  if  value  not  found  : 

$NEXT7  $DELErE_MICROFILM 
;Must  value  exist  Y/N  : 

N 

$NEXT7 

DELETE  FBOM  JOIN 

WHERE  JOINED  IN  (SELECT  MiN  FROM  TO_DELETE) 

/ 

;Messa£e  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

$DELETE_MICROFILM 
SELECT  *  FROM  MICROFILM 
WHERE  DRN  IN  (SELECT  DRN  FROM  TO_DELETE) 
/ 

;Messa2e  if  value  not  found  : 

$NEXT8  $DELETE_SUBJECT 
;Must  value  exist  Y/N  : 

N 

$NEXT8 

DELETE  FROM  MICROFIIH 

WHERE  IRN  IN  (SELECT  ERN  FROM  TO_DELETE) 

/ 

;Messa£e  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

$DELETE_SUBJECT 
SELECT  *  FROM  SUBJECT 

WHERE  DRN  IN  (SELECT  IRN  FROM  TO_DELErE) 

/ 

; Message  if  value  not  found  : 

$NEXT9  $UPDATE_DOCUMENT 
;Must  value  exist  Y/N  ; 

N 

$NE5Cr9 

DELETE  FROM  SUBJECT 

WHERE  IRN  IN  (SELECT  DRN  FROM  TO_DELErE) 

/ 

;Message  if  value  not  found  : 


;Nust  value  exist  Y/N  : 

Y 

$UPDATE_DOCUMENT 
UPDATE  DOCUMENT 
SET  PCRMSTS  =  ’D’ 

WHERE  IRN  IN  (SELECT  IRN  FROM  TO_DELETE) 

/ 

;Message  if  value  not  found  : 
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;Must  value  exist  Y/N  : 

Y 

INSERT  INTO  REFERENCE  (MiN,  REFER) 
SELECT  TO_DELETE.I»lN,  .-REFERENCE 
FROM  TO_DELETE 

/ 

;Messa£e  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

DELETE  FROM  TO_DELETE 
; Message  if  value  not  found  : 

;Must  value  exist  Y/N  ; 

Y 


Form  A24 .  Join  Documents ,  Block  Join 

Remark:  This  trigger  performs  the  integrity  rules  necessary  to  join  two 
documents . 

♦PRE-INSERT 

;SQL> 

SELECT  ’X’  FROM  DUAL 
WHERE  :MAIN  O  : JOINED 
/ 

; Message  if  value  not  found  : 

Main  and  Joined  cannot  be  the  same  document. 

;Must  value  exist  Y/N  : 

Y 

SELECT  ♦  FROM  DOCUMENT 
WHERE  DRN  IN  (: MAIN, : JOINED) 

PC*  UPDATE  OF  JOINSTS 

/ 

;Mess£ige  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  DOC_LOG  IN  SHARE  UPDATE  >0)E 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  HOLDER  IN  SHARE  UPDATE  MODE 

/ 

;Me8sage  if  value  not  found  : 

;  leftist  value  exist  Y/N  : 

Y 

UPDATE  DOCUMENT 
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SET  JOINSTS  =  ’M’ 

WHERE  I®N  =  :MAIN 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

UPDATE  DCXUMENT 
SET  JOINSTS  =  ’J' 

WHERE  DRN  =  : JOINED 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

DELETE  FROM  DOC_LOG 
WHERE  DRN  =  : JOINED 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/K  : 

Y 

DELETE  FEOM  HOLDER 
WHERE  DRN  =  : JOINED 

; Message  if  value  not  found  : 

;Muat  value  exist  Y/N  : 

Y 


Remark:  This  trigger  executes  the  integrity  rules  necessary  to  sepeurate 
two  documents  that  were  joined  before. 

^FRE*~  DELETE 
;SQL> 

SELECT  *  FROM  DOCUMENT 
WHERE  M?N  IN  (: MAIN, :  JOINED) 

FCR  UPDATE  OF  JOINSTS 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

UPDATE  DOCUMENT 
SET  JOINSTS  =  ’I’ 

WHERE  MiN  =  rJOINED 

/ 

; Message  if  value  not  found  : 

;Muat  value  exist  Y/N  : 

Y 
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INSERT  INTO  HOLDER  (DRN,  NAME,  DEPOODE) 
SELECT  : JOINED,  NAME,  DEPOODE 
FROM  HOLDER 
WHERE  EKN  =  :MAIN 
/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

INSERT  INTO  DOC_LOG  (DRN,  LDATE,  LTIME,  SEND_DEP,  REC_DEP) 
SELECT  : JOINED,  LDATE,  LTIME,  SEND_DEP,  REC_DEP 
FRCM  DOC_LOG_VIEW 
WHERE  DRN  =  :MAIN 

AND  JULIAN_D_T  =  (SELECT  MAX (ALL  JULIAN_DJD 
FROM  DOC_LOG_VIEW 
WHERE  E«N  =  .-MAIN) 

/ 

(Message  if  value  not  found  : 

(Must  value  exist  Y/N  : 

Y 

SELECT  *  FROM  JOIN 
WHERE  MAIN  =  :MAIN 
AND  JOINED  <>  (JOINED 
/ 

(Message  if  value  not  found  : 

SEND  $ 

(Must  value  exist  Y/N  : 

N 

UPDATE  DOCUMENT 
SET  JOINSTS  =  'I' 

WHERE  DRN  =  (MAIN 

(Message  if  value  not  found  ( 

(Must  value  exist  Y/N  ( 

Y 


Form  A251 ,  Transfer  Department  Custody,  Block  Doc  Log 

Reimrk(  This  trigger  verities  whether  the  sending  department  in  a 
document  transference  has  received  the  document  previously.  If  it  was, 
set  History  Status  equal  "N"ornial,  if  not,  set  it  equal  "A'Tteration. 
♦POST-INSERT 
(SQL> 

SELECT  ♦ 

FROM  DOCJjOG  Y 
WHERE  EXISTS 
( 

SELECT  » 

FROM  DOC  LOG  X 


146 


WHERE  I»{N  =  :rs^ 


AND  Y.TON  =  DRN 


AND  Y.SEND_DEP  <>  REC_DEP 
AND  TO_NUMBER 

{TO_CHAR  (Y.IDATE, 'J’ )  ,'!  SUBSTR{Y.LTIME,  1 , 2 ) 

i;  SUBSTR(Y.LTIME,4,2)) 
=  (SELECT  MIN  (ALL  TO_NUMBER 

(TO_CHAR  (LDATE/JM 
!!  SUBSTR(LTIME,1,2) 
li  SUBSTR(LTIME,4,2) ) ) 


FROM  DOC_LOG 

WHERE  DRN  =  :DRN 

AND  TO_CHAR  (LDATE.’J’)  i: 

I  I 
I  I 

> 

TOJCHAR  (X.LDATE.’J*) 

) 


SUBSTR(LTIME,1,2) 

SUBSTR(LTIME,4,2) 

!!  SUBSTR(X.LTIME,1,2) 
j;  SUBSTR{X.LTIME,4,2) 


) 

/ 

; Message  if  value  not  found  : 
$SET_ALTERATICW  $SET_NC«MAL 
;Must  value  exist  Y/N  : 

N 

$SET_NC«MAL 

LOCK  TABLE  DOCUMENT  IN  SHARE  UPDATE  MODE 


/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

UPDATE  DOCUMENT 
SET  HISTSTS  =  ’N’ 

WHERE  DRN  =  :DOC_LOG.I®N 

/ 

; Message  if  value  not  found  : 

$END  $ 

;Must  value  exist  Y/N  : 

Y 

$SET_ALTERATION 

LOCK  TABLE  DOCUMENT  IN  SHARE  UPDATE  MODE 

/ 

;Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

UPDATE  DOCUMENT 
SET  HISTSTS  =  ’A’ 

WHERE  E«N  =  :DOC_LOG.EKN 

;Message  if  value  not  found  : 
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;Must  value  exist  Y/N  : 
Y 


Field  raw. 

Remark:  This  trigger  verifies: 

1)  Whether  the  document  exists.  If  the  document  already  hats  a  row 
in  the  table  DocJLog,  is  because  it  exists,  and  it  is  not  a  joined 
nor  a  destroyed  docunent. 

2)  Whether  the  docunent  is  a  joined  document  in  a  join 
relationship. 

3)  Whether  the  document  is  a  destroyed  document. 

»»POST-CHANGE\ 

/ 

;SQL> 

SELECT  *  FROM  DOCJjOG 
WHERE  DRN  =  :DRN 
/ 

; Message  if  value  not  found  : 

$END  $ 

;Must  value  exist  Y/N  : 

N 

SELECT  *  FROM  DOCUMENT 
WHERE  DRN  =  :E«N 
/ 

;MesssLge  if  value  not  found  : 

This  document  does  not  exist. 

;Must  value  exist  Y/N  : 

Y 

SELECT  *  FROM  DOCUMENT 
WHERE  E«N  =  :I®N 
AND  JOINSTS  =  ’J’ 

/ 

;Message  if  value  not  found  : 

*This  document  is  Joined.  It  cannot  be  transferred  alone. 

;Must  value  exist  Y/N  : 

Y 

SELECT  *  FROM  DOCIWENT 
WHERE  im  =  :WN 
AND  FOTMSTS  =  ’D’ 

;Message  if  value  not  found  : 

♦This  document  was  destroyed. 

;Must  value  exist  Y/N  : 

Y 
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Form  A322.  Look  Up  Thesaurvis  Terms  and  Relationships 
Form  Level. 

Remark:  This  trigger  uses  variable  reference  {kvar) .  It  copies  the 
contents  of  the  current  field  in  the  form  to  a  global  variable.  This  is 
used  to  paste  the  copied  field  in  another  field  elsewhere,  in  the  calling 
module. 

*»KEY-MENU 

;SQL> 

#OOPY  &SYSTEM.CURRENT_FIELD  GLOBAL. VAR 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Block  Terms,  Field  ClassCd . 

Remark:  This  trigger  selects  the  class  name  into  the  field  Class,  on  the 
screen,  that  corresponds  to  the  code  entered  in  the  field  ClassCd. 
»»POST-CHANGE 
/ 

;SQL> 

SELECT  CLASS  INTO  :CLASS 
FROM  CLASSES 

WHERE  CLASSCD  =  : CLASSCD 
;Message  if  value  not  found  : 

Ibis  class  does  not  exist.  Press  F9  to  see  list  of  values. 

;Must  value  exist  Y/N  : 

Y 


Form  A36.  Show  Statistics ,  Block  A36 


Ranark:  This  trigger  accesses  several  tables  to  compute  statistics.  Ihe 
form  does  not  have  a  base  table. 

*KEY-MENU 

;SQL> 

SELECT  OOUNT(ALL  DRN)  INTO  TOTAL 
FROM  DOCUMENT 

WHERE  ISSUEDT  BETWEEN  :FROMDT  AND  :TC»T 

/ 

;Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  AVG(  ALL  (  MAX(ALL  LDATE)  -  MIN(ALL  LDATE)  +  1)  ), 
STDDEV(  ALL  (  MAX(ALL  IDATE)  -  MIN(ALL  LDATE)  +  1)  ) 
INTO  AVCaOAYS,  STDDAYS, 
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FROM  DOC_LCG 

WHERE  I»N  IN  (SELECT  IffiN 

FROM  DOCUMENT 
WHERE  FROCSTS  =  ’S’ 

AND  ISSUEDT 

BETWEEN  :FROMDT  AND  :TODT) 

GROUP  BY  ORN 

/*  This  standard  deviation  is  UNBIASED  */ 

/ 

;Messa£e  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  FORMSTS)  INTO  PAPER 
FROM  DOCUMENT 
WHERE  FCRMSTS  =  ’P’ 

AND  ISSUEDT  BETWEEN  :FROMDT  AND  :TODT 

/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  FtDRMSTS)  INTO  MICROFIl^l 
FROM  DOCUMENT 
WHERE  PCfiMSTS  =  ’M’ 

AND  ISSUEDT  BETWEEN  :FR0MDT  AND  cTCXT 

/ 

;Me8sage  if  value  not  found  : 


:Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  PCRMSTS)  INTO  DESTROYED 
FROM  DOCUMENT 
WHERE  FORMSTS  =  ’D’ 

AND  ISSUEDT  BETWEEN  :FROMDT  AND  :TC»T 

/ 

;Mes8age  if  value  not  found  : 


;Must  valt>e  exist  Y/N  : 

Y 

SELECT  COUNT (ALL  JOINSTS)  INTO  INDEPENDENT 
FROM  DOCUMENT 
WHERE  JOINSTS  =  ’I’ 

AND  ISSUEDT  BETWEEN  ;FR0MDT  AND  :TC®T 

/ 

;MesBage  if  value  not  found  : 

;Mu8t  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  JOINSTS)  INTO  MAIN 
FROM  DOCUMENT 
WHERE  JOINSTS  =  'M’ 
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AND  ISSUEDT  BEWEEN  :FKM)T  AND  CTODT 

/ 

;Message  if  value  not  fotmd  : 


;Must  value  exist  Y/N  : 

Y 

SELECTT  COUNT (ALL  JOINSTS)  INTO  JOINED 
FROM  DOCUMENT 
WHERE  JOINSTS  =  ’J’ 

AND  ISSUEDT  BETOEEN  :FHOMDT  AND  :TODT 

/ 

;Messa£e  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  PHOCSTS)  INTO  PROCESSING 
FROM  DOCUMENT 
WHERE  PROCSTS  =  ’P’ 

AND  ISSUEDT  BETWEEN  :FR0MDT  AND  :TODT 

/ 

:Messa£e  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  COUNT (ALL  PROCSTS)  INTO  WAITING 
FROM  DOCUMENT 
WHERE  PROCSTS  =  ’W* 

AND  ISSUEDT  BEWEEN  :FROMDT  AND  :TODT 

/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  PROCSTS)  INTO  SOLVED 
FROM  DOCUMENT 
WHERE  PROCSTS  =  'S’ 

AND  ISSUEDT  BETVEEN  rFROMDT  AND  :TODT 

/ 

;Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  COUNT(ALL  HISTSTS)  INTO  NC»?MAL 
FROM  DOCUMENT 
WHERE  HISTSTS  =  ’N’ 

AND  ISSUEDT  BETIVEEN  :FR0MDT  AND  :TODT 

/ 

;Me88age  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  COUNT(ALL  HISTSTS)  INTO  ALTERATICW 
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FTWM  DOCUMEMT 
VWERE  HISTSTS  =  ’A' 

AND  ISSUEDT  BETVEEN  :FR0MDT  AND  :TC®T 

/ 

;Messa£e  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  CXXJNT(ALL  ARCHSTS)  INTO  UNCLASSIFIED 
FTWM  DOCUMENT 
WHERE  ARCHSTS  =  ’U’ 

AND  ISSUEDT  BETWEEN  iFBOMDT  AND  :TODT 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  COUNT (ALL  ARCHSTS)  INTO  CLASSIFIED 
FROM  DOCUMENT 
WHERE  ARCHSTS  =  ’C' 

AND  ISSUEDT  BEIVEEN  :FBOMDT  AND  ;TODT 

/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT 

{: PAPER/: TOTAL) *100,  ( :MICR0FI1M/: TOTAL) *100,  ( tDESTOOYED/: TOTAL) *100, 
(: INDEPENDENT/; TOTAL) *100,  (: MAIN/: TOTAL) *100,  (: JOINED/: TOTAL) *100, 

(: PROCESSING/; TOTAL) *100,  (; WAITING/: TOTAL) *100,  (: SOLVED/: TOTAL) *100, 
( :NC«MAL/ : TOTAL) *100,  ( :ALTERATICW/: TOTAL) *100, 

( :CLASSIFIED/:T0TAL)*100,  ( : UNCLASSIFIED/: TOTAL) *100 
INTO 

PPAPER,  PMICBOFIU^,  PDESTROYED, 

PINDEPENDENT,  PMAIN,  pjoined, 

PPROCESSING,  PWAITING,  PSOLVED, 

PNORMAL,  PALTERATION, 

PCLASSIFIED,  PUNCLASSIFIED 
FROM  DUAL 
/ 

;Message  if  value  not  foimd  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  CLASSCD)  INTO  CLASSES 
FROM  CLASSES 
/ 

;Mes8age  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  TERM)  INTO  TERMS 


152 


FROM  TERMS 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  NOTE)  INTO  NOTES 
FROM  NOTES 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  COUNT(ALL  MAINTR) 

INTO  RELSHIPS 
FROM  RELSHIPS 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  COUNT (DISTINCT  DRN)  INTO  INDEXED 
FROM  SUBJECT 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

SELECT  (: INDEXED/: TOTAL)  *  100 
INTO  PINDEXED 
FROM  DUAL 
/ 

(Message  if  value  not  found  : 

(Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  WiN)  /  OOUNT(DISTINCT  E«N)  AVERAGE 
INTO  AVGTERM 
FROM  SUBJECT 
/ 

(Message  if  value  not  found  : 

(Must  value  exist  Y/N  : 

Y 

SELECT  OOUNT(ALL  DRN)  /  OOUNT(DISTINCT  DRN)  AVERAGE, 

STDDEV  (  ALL  (OOUNT(ALL  E«N)  /  OOUNT(DISTINCT  DRN))  ) 

"STANDARD  DEV" 

INTO  STDTERM 
FROM  SUBJECT 
GKOUP  BY  I»N 

(Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 
Y 


Form  A41 ,  Maintain  Classes .  Block  Classes 

Remark:  Hiis  trigger  does  the  following  automatic  insertions: 

1 )  Insert  the  class  name  as  a  term  in  the  table  TERMS . 

2)  Insert  the  scope  note  "class". 

3)  Connect  the  term  to  the  root  of  the  hierarchical  tree. 

»PRE- INSERT 

;SQL> 

INSERT  INTO  TERMS  ( TERM ,  CLASSCD ) 

VALUES  (: CLASS, : CLASSCD) 

/*  Insert  the  class  name  as  a  term  in  the  table  TERMS 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

INSERT  INTO  NOTES  (TERM, NOTE) 

VALUES  (: CLASS, 'CLASS’ ) 

/*  Insert  the  word  CLASS  as  a  scope  note  for  the  term  that 
/*  corresponds  to  a  claiss 
/ 

jMessage  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

INSERT  INTO  RELSHIPS  (MAINTR,REL,SECTR) 

VALUES  (:CLASS,’BT’,’ROOT’) 

/*  Create  a  hierarchical  relationship  having  ROOT  as  the  parent  and  the 
/*  claiss  being  inserted  as  the  child 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

INSERT  INTO  RELSHIPS  (MAINTR,REL,SECrrR) 

VALUES  ('ROOT’,’NT’,:CLASS) 

/*  Create  a  hierarchical  relationship  having  BOCT  as  the  parent  and  the 
/*  class  being  inserted  as  the  child 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 
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1 


Remark:  This  trigger  verifies  whether  the  user  is  trying  to  update  a 
system  maintained  cleiss  and  performs  integrity  operations  related  to  the 
update  being  made  in  the  table  class. 

*reE-UPDATE 

;SQL> 

SELECT  »  FROM  CLASSES 
WHERE  ROWID  =  :ROWID 

AND  (CLASSCD  =  '00’  OR  CLASSCD  =  '01') 

/*  Do  not  permit  to  update  classes  00  or  01 

/ 

;Mess£Lge  if  value  not  found  : 

♦This  class  is  owned  by  the  system.  Update  is  not  allowed. 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  SUBJECT  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

UPDATE  SUBJECT 
SET  TERM  =  :CLASS 

WHERE  TERM  =  (SELECT  CLASS  FROM  CLASSES 
WHERE  ROWID  =  :R0WID) 

/*  update  all  rows  that  have  the  old  class  name  as  the  term 

/ 

{Message  if  value  not  found  : 

{Must  value  exist  Y/N  : 

N 

LOCK  TABLE  TERMS  IN  SHARE  UPDATE  MODE 

/ 

{Message  if  value  not  found  ; 

{Must  value  exist  Y/N  : 

Y 

UPDATE  TERMS  SET  TERM  =  .'CLASS 
WHERE  TERM  =  (SELECT  CLASS  FROM  CLASSES 
WHERE  ROWID  =  :R0WID) 

/*  Update  the  corresponding  term  in  the  table  TERMS 

/ 

{Message  if  value  not  found  ; 

{Must  value  exist  Y/N  : 

N 

SELECT  'X'  FROM  DUAL 
WHERE 

:CLASSCD  =  (SELECT  CLASSCD  FROM  CLASSES 
WHERE  ROWID  =  :R0WID) 

/*  it  is  being  tested  vdiether  the  class  code  was  changed.  If  not 
/*  there  is  no  necessity  of  updating  the  claiss  code  of  terms 
/*  that  pertain  to  the  class  being  updated 
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/♦  if  the  step  sxxxseeds,  branch  to  update  table  Notes 

/ 

;Message  if  value  not  found  : 

$UPDATE_NOTES  $ 

;Must  value  exist  Y/N  ; 

N 

UPDATE  TERMS 

SET  CLASSCD  =  :CLASSCD 

WHERE  CLASSCD  =  (SELECT  CLASSCD  FROM  CLASSES 
WHERE  BOWID  =  :ROWID) 

/*  Update  all  rows  in  table  Terms  that  have  the  same  cleiss  code 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

$UPDATE_NOTES 

LOCK  TABLE  NOTES  IN  SHARE  UPDATE  MODE 
/t  Update  the  term  in  the  table  Relship>s 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

UPDATE  NOTES 
SET  TEia^  =  ;CLASS 

WHERE  TERM  =  (SELECT  CLASS  FROM  CLASSES 
WHERE  ROWID  =  :ROWID) 

/♦  As  a  class  is  also  a  terra,  it  may  have  scope  notes  to  be  updated 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

LOCK  TABLE  RELSHIPS  IN  SHARE  UPDATE  MODE 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

UPDATE  RELSHIPS 
SET  MAINTR  =  : CLASS 

WHERE  MAINTR  =  (SELECT  CLASS  FTOM  CLASSES 
WHERE  ROWID  =  :HOWID) 

/»  update  all  rows  that  have  the  old  cleiss  name  as  the  main  term 

/ 

;Me8sage  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

UPDATE  RELSHIPS 
SET  SECm  =  :CLASS 
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WHERE  SECTR  =  (SELECT  CLASS  FROM  CLASSES 
WHERE  ROWID  =  :RCIWID) 

/»  update  all  rows  that  have  the  old  class  name  as  the  secondary  term 

;Message  if  valiie  not  found  : 

;Must  value  exist  Y/N  : 

N 


Remark:  This  trigger  verifies  vhether  the  user  is  trying  to  delete  a 
system  maintained  class  and  performs  integrity  operations  related  to  the 
deletion  being  made  in  the  table  class. 

»FRE-DELETE 

;SQL> 

SELECT  *  FROM  CLASSES 
WHERE  ROWID  =  : ROWID 

AND  (CLASSCD  =  *00’  OR  CLASSCD  =  *01’) 

/»  Do  not  permit  to  delete  classes  00  or  01 

/ 

; Message  if  value  not  found  : 

♦This  class  is  owned  by  the  system.  Deleting  is  not  allowed. 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  SUBJECT  IN  SHARE  UPDATE  MC»E 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

DELETE  FROM  SUBJECT 

WHERE  TEWi  IN  (SELECT  TERM  FROM  TERMS 

WHERE  CLASSCD  =  :CLASSCD) 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

LOCK  TABLE  TERMS  IN  SHARE  UPDATE  MODE 

/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  NOTES  IN  SHARE  UPDATE  MODE 

/ 

;Mes8age  if  value  not  found  : 


;Must  value  exist  Y/N  : 
Y 

DELETE  FROM  NOTES 
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WHERE  TERM  IN  (SELECT  TERM  FBOM  TERMS 
WHERE  CLASSCD  =  :CLASSCD) 

/ 

;Messei£e  if  value  not  found  ; 

;Must  value  exist  Y/N  : 

N 

LOCK  TABLE  RELSHIPS  IN  SHARE  UPDATE  MODE 

/ 

;Messa£e  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

DELETE  FROM  RELSHIPS 

WHERE  MAINTR  IN  (SELECT  TERM  FROM  TERMS 

WHERE  CLASSCD  =  tCLASSCD) 
OR  SECTR  IN  (SELECT  TERM  FROM  TERMS 

WHERE  CLASSCD  =  tCLASSCD) 

/ 

;Message  if  value  not  fo\jnd  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  TERMS 
WHERE  CLASSCD  s  tCLASSCD 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 


Remark:  This  trigger  is  an  example  of  redefining  a  key  to  comnit  an 
operation  immediately  after  executing  it.  ITiis  avoids  the  accunulation 
of  operations  not  comnitted  that  would  be  all  rolled  back  in  an  eventual 
error.  This  also  releases  the  locks  requested  by  triggers.  Ibis 
redefinition  is  also  used  in  the  "key-delrec"  trigger. 

*KEY-CREREC 

;SQL> 

#E3®1ACH0  CREREC;  COMMIT; 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 
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Form  A42.  Maintain  Terms,  Block  Terms 

Remark:  Tliis  trigger  performs  integrity  operations  related  with  a  term 
update. 

CPRE-UPDATE 

;SQL> 

SELECT  »  FliOM  CLASSES 

WHERE  CLASS  =  (  SELECT  TERM  FROM  TERMS 

WHERE  ROWID  =  rTEHtS.HOWID) 

/*  do  not  permit  to  update  a  term  that  corresponds  to  a  claiss 

/ 

; Message  if  value  not  found  : 

♦Term  corresponds  to  a  class  name.  Use  A41-Maintain  Classes. 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  SUBJECT  IN  SHARE  UPDATE  ^^»E 
/♦  Update  the  term  in  the  table  Subject. 

/♦As  the  old  name  is  not  anymore  in  the  form,  we  use  the  rowid  to 
/♦  find  the  matches  in  the  table  Subject. 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

UPDATE  SUBJECT 

SET  TERM  =  :TERMS.TERM 

WHERE  TERM  =  (SELECT  TERM  FROM  TERMS 

WHERE  TERMS. ROWID  =  :TERMS. ROWID) 

/ 

(Message  if  value  not  found  : 

(Must  value  exist  Y/N  : 

N 

LOCK  TABLE  NOTES  IN  SHARE  UPDATE  MODE 
/♦  Update  the  term  in  the  table  Relships 
/ 

(Message  if  value  not  found  : 

(Must  value  exist  Y/N  : 

Y 

UPDATE  NOTES 

SET  TERM  =  :TERMS.TERM 

WHERE  TERM  =  (SELECT  TERM  FROM  TERMS 

WHERE  TERMS. ROWID  =  :TERMS. ROWID) 

/ 

(Message  if  value  not  found  : 

(Must  value  exist  Y/N  : 

N 

LOCK  TABLE  RELSHIPS  IN  SHARE  UPDATE  MODE 
/♦  Update  the  term  in  the  table  Relships 
/ 
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; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

UPDATE  RELSHIPS 

SET  MAINTR  =  rTERMS.TEKi 

WHERE  MAINTR  =  (SELECT  TERM  FROM  TERMS 

WHERE  TERMS. ROWID  =  :TERMS.ROWID) 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

UPDATE  RELSHIPS 

SET  SECTR  =  :TERMS.TEia>l 

WHERE  SECTR  =  (SELECT  TERM  FROM  TERMS 

WHERE  TERMS. ROWID  =  :TERMS. ROWID) 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 


Remark:  This  trigger  performs  integrity  operations  related  with  a  term 
deletion. 

»PRE-DELETE 

;SQL> 

SELECT  »  FROM  CLASSES 

WHERE  CLASS  =  (  SELECT  TERM  FROM  TERMS 

WHERE  ROWID  =  :TERMS. ROWID) 

/*  do  not  permit  to  delete  the  term  that  corresponds  to  a  class 

/ 

; Message  if  value  not  found  : 

♦Term  corresponds  to  a  class  name.  Use  A41 -Maintain  Claisses. 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  SUBJECT  IN  SHARE  UPDATE  MODE 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

DELETE  FROM  SUBJECT 
WHERE  TERM  =  :TERMS.TERM 
/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

LOCK  TABLE  NOTES  IN  SHARE  UPDATE  MCDE 
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/ 

;Mess£Lge  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

LOCK  TABLE  RELSHIPS  IN  SHARE  UPDATE  MC®E 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

$VERIFY_RELSHIPS 
SELECT  MAINTR,  REL,  SECTR 
INTO  MAINTR,  REL,  SECTR 
FROM  RELSHIPS 

WHERE  MAINTR  =  :TERMS.TEE^ 

AND  REL  =  ’BT’ 

/*  verify  if  the  term  being  deleted  is  involved  in  a  hierarchical 
/»  relationship.  If  it  is,  the  values  of  maintr,  rel  and  sectr  are 
/*  copied  to  control  fields  for  the  purpose  of  disconnecting  the 
/*  term  from  the  hierarchical  tree  and  the  disconnecting  step  is  called 
/*  if  the  term  does  not  have  relationships,  proceed  to  delete 
/*  all  rows  that  have  either  the  main  or  secondary  term  equal 
/*  the  term  being  deleted 
/ 

; Message  if  value  not  found  : 

$DISOONNECT  $DEL_RELSHIPS 
;Must  value  exist  Y/N  : 

N 

;  call  trigger  to  disconnect  the  term  from  a  node  in  the 
;  table  Relships.  Only  one  node  is  disconnected  at  a  time. 

;  When  returning,  deviate  to  the  beginning  to  verify 
;  whether  still  exists  any  hierarchical  relationships 
;  Keep  looping  until  all  hierar.  rel.  were  disconnected. 

$DISOONNECT 

#EXEMACRO  EXETOG  DISCONNECT_NCOE 

/ 

;Message  if  value  not  found  : 

$VERIFY_RELSHIPS  $ 

;Must  value  exist  Y/N  : 

Y 

$DEL_REL5HIPS 
DELETE  FROM  RELSHIPS 
WHERE  MAINTR  =  :TERMS.TERM 
C*?  SECIR  =  :TERMS.TERM 
/ 

;Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  NOTES 
WHERE  TERM  =  :TERMS.TERM 
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/*  Do  not  abort  trigger  v^ien  step  fails  */ 

;Messa£e  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 


Remark:  This  trigger  uses  variable  reference  (tvar).  It  copies  the 
contents  of  a  global  variable  to  the  current  field  in  the  form.  This  is 
used  to  paste  a  field  copied  from  this  or  from  another  form  inside  a 
field  in  this  module.  See  the  following  trigger  and  also  a  trigger  in 
form  A322  that  are  used  in  combination  with  this  one. 

»KEY-C31EREC 

;SQL> 

#OOPY  GLOBAL. VAR  rTERMS.TERM 

: Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Remark;  This  trigger  is  used  in  combination  with  the  previous  trigger  to 
"cut  and  peiste"  field  values. 

;SQL> 

#OOPY  :TERMS.TERM  GLCffiAL.VAR 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


Remark:  This  trigger  is  used  to  disconnect  a  hierarchical  relationship  in 
the  table  Relships.  This  trigger  is  called  from  another  trigger. 
»DISCX»JNECT_NC»E 
;SQL> 

;  disconnect  a  hierarchical  relationship  from  the 

;  hierarchical  tree 

UPDATE  RELSHIPS 

SET  MAINTO  =  :SECrrR 

WHERE  MAINTO  =  :MAINTO 

AND  REL  =  'NT' 

/*  If  the  term  hais  a  child,  connect  its  child  to  its  parent 

/ 

; Message  if  value  not  found  : 
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;^hJst  value  exist  Y/N  : 

N 

UPDATE  RELSHIPS 
SET  SECTO  =  :SECTR 
WHERE  SECTR  =  iMAINra 
AND  REL  =  ’BT’ 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  RELSHIPS 

WHERE  MAINTR  =  :MAINTR  AND  SECTR  =  :SErTR  AND  REL  =  ’BT’ 
/*  delete  the  relationship 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  RELSHIPS 

WHERE  MAINTR  =  cSECTR  AND  SECTR  =  :MAINTR  AND  REL  =  ’NT’ 
/♦  If  there  exists,  deletes  the  reciprocal 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 


Form  A43,  Maintain  Relationships ,  Block  Relships 

Remark:  This  form  uses  user-defined  triggers  in  combination  with 
pre-insert,  pre-update  and  pre-delete  triggers  to  enforce  integrity  rules 
in  insertions,  updates  and  deletions  executed  in  the  table  Relships. 

Each  kind  of  relationship  has  its  particular  rules.  A  C£ise  statement 
identifies  the  relation  involved  auid  calls  the  appropriated  trigger. 


♦PRE-INSERT 

;SQL> 

tEXFMACBO  CASE  :REL  IS 

WHEN  ’RT’  TOEN  EXETRG  INSERTJRT; 

WHEN  ’US’  THEN  EXETRG  INSERTJUS; 

WHEN  ’UF’  THEN  EXETRG  INSERTJUF; 

WHEN  ’BT’  THEN  EXETRG  INSERT_BT; 

WHEN  ’NT’  THEN  EXETRG  INSERT_NT; 

END  CASE; 


;Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 
Y 
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»PRE-UPDATE 

;SQL> 

SELECT  *  FW3M  RELSHIPS 
WHERE  BOWID  =  :BOWID 

AND  (MAINTR  =  ’ROOT’  C*  SECTR  =  ’BOOT’ ) 

/ 

;Messa£e  if  value  not  found  ; 

♦Relationship  owned  by  the  systan.  Updating  not  allowed. 
;Must  value  exist  Y/N  : 

Y 

#EXaiACRO  CASE  :REL  IS 

WHEN  ’RT’  THEN  EXETRG  UPDATE_RT; 

WHEN  ’US’  THEN  EXETRG  UPDATEJLTS; 

WHEN  ’UF’  THEN  EXETRG  UPDATEJUF; 

WHEN  ’BT’  THEN  EXETRG  UPDATE_BT; 

WHEN  ’NT’  THEN  EXETRG  UPDATE_NT; 

END  CASE; 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


♦PRE-DELETE 

;SQL> 

#EXEMACRO  CASE  :REL  IS 

WHEN  ’RT’  THEN  EXETRG  DELRT; 

WHEN  ’US’  THEN  EXETRG  DELUS; 

WHEN  ’UF’  THEN  EXETRG  DELUF; 

WHEN  ’BT’  THEN  EXETRG  DELBT; 

WHEN  ’NT’  THEN  EXETRG  DELNT; 

END  CASE; 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


♦INSERT_BT 

;SQL> 

INSERT  INTO  RELSHIPS  VALUES 
(rSBCTR,  ’NT’,  :MAINTR) 

/♦  Insert  the  reciprocal  of  the  relaticxiship 

/ 

;Message  if  value  not  found  : 
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;Must  value  exist  Y/N  : 

Y 

SELECT  ’X'  FROM  RELSHIPS 

WHERE  ( :SECTR  =  'ROOT' )  CXi  (MAINTR  =  :SECTR  AND  REL  =  ’BT’  ) 

/*  If  the  secondary  term  already-  has  a  BROADER  TERM 
/*  relationship  goto  END 

/*  Otherwise,  we  connect  the  sectr  to  the  class  that  it  pertains 
/*  This  action  is  intended  to  not  permit  hierarchical  relationship® 
/*  that  disconnected  from  the  hierarchical  tree 
/ 

; Message  if  value  not  found  : 

$END  $ 

;Must  value  exist  Y/N  : 

N 

INSERT  INTO  RELSHIPS  (MAINTR, REL, SECTR) 

SELECT  :SECTR,  ’BT’ ,  CLASS 
FROM  CLASSES 

WHERE  CLASSCD  =  :SEOCLASSCD 

/*  Insert  a  BROADER  TERM  relationship  that  has  the  secondary  term 
/*  being  inserted  as  the  main  term  and  its  class  as  the 
/*  second  \ry  term 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

INSERT  INTO  RELSHIPS  (MAINTR, REL, SECTR) 

SELECT  CLASS,  ’NT’,  :SECTR 
FROM  CLASSES 

WHERE  CLASSCD  =  :SECCLASSCD 
/*  Insert  the  reciprocal 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


*INSERT_NT 

;SQL> 

INSERT  INTO  RELSHIPS  VALUES 
(:SBCTR,  ’BT’,  :MAINTR) 

/»  Insert  the  reciprocal  of  the  relationship 

/ 

;Mes8age  if  value  not  found  : 

:Must  value  exist  Y/N  : 

Y 

SELECT  ’X’  FROM  RELSHIPS 

WHERE  (rMAINTR  =  ’ROOT’)  OR  (MAINTR  =  :MAINTR  AND  REL  =  ’BT’) 
/*  If  the  main  term  has  a  BROADER  TEiai  relationship  goto  END 
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/ 

;Message  if  value  not  found  ; 

SEND  $ 

;Must  value  exist  Y/N  ; 

N 

INSERT  INTO  RELSHIPS  (MAINTR.REL.SECTR) 

SELECT  rMAINTO,  ’BT’ ,  CLASS 
FROM  CLASSES 

WHERE  CLASSCD  =  :MAINCLASSCD 

/*  Insert  a  BROADER  TEK^  relationship  that  hsis  the  class  of  the  term 
/*  being  inserted  ais  its  BROADER  TERM 
/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 

INSERT  INTO  RELSHIPS  (MAINTR.REL.SECTR) 

SELECT  CLASS.  ’NT’.  :MAINTR 
FROM  CLASSES 

WHERE  CLASSCD  =  :MAINCLASSCD 
/♦  Insert  the  reciprocal 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


*INSERT_RT 

;SQL> 

INSERT  INTO  RELSHIPS  VALUES 
(rSECTR.  ’RT’.  :MAINTR) 

/*  Insert  the  reciprocal  associative  entry 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


»INSERT_UF 

;SQL> 

INSERT  INTO  RELSHIPS  VALUES 
(:SECTR.  ’US’,  :MAINTR) 

/*  Insert  the  reciprocal  and  goto  END 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 
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»INSERT_US 

;SQL> 

INSERT  INTO  RELSHIPS  VALUES 
(rSECTR,  'UF',  :MAINTR) 

/»  Insert  the  reciprcxjal 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


♦UPDATEJBT 

;SQL> 

SELECT  ’X’  FROM  DUAL 

WHERE  .-MAINCLASSCD  =  rSECCLASSCD 

/»  If  both  terms  in  a  hierarchical  relat.  do  not  pertain  to  the  same 
/*  class  give  error  message 
/ 

; Message  if  value  not  found  : 

In  a  hierarchical  relationship  both  terms  must  pertain  to  the  same  class. 
;Must  value  exist  Y/N  : 

Y 

UPDATE  RELSHIPS 
SET  SECTR  =  :MAINTR 
WHERE  MAINTR  =  : SECTR 
AND  REL  =  ’NT’ 

AND  SECTR  =  (SELECT  MAINTR  FROM  RELSHIPS 
WHERE  ROWID  =  :ROWID) 

/*  Ufxiate  the  reciprocal  of  the  relationship 
jMessaige  if  value  not  found  : 

;Must  value  exist  Y/N  ; 

Y 


»UPDATE_NT 

;SQL> 

SELECT  ’X’  FROM  DUAL 

WHERE  : MAINCLASSCD  =  :SEOCLASSCD 

/*  If  both  terms  in  a  hierarchical  relat.  do  not  pertain  to  the  same 
/*  class  give  error  message 
/ 

; Message  if  value  not  found  : 

In  a  hierarchical  relationship  both  terms  must  pertain  to  the  same  class. 
;Must  value  exist  Y/N  : 
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Y 

UPDATE  RELSHIPS 
SET  SECTR  =  :MAINTR 
WHERE  MAINTO  =  rSECTR 
AND  REL  =  ’BT’ 

AND  SECTR  =  (SELECT  MAINTR  FRCW  RELSHIPS 
WHERE  HOWID  =  :ROWID) 

/*  Update  the  reciprocal  of  the  relationship 
;Mess8ige  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


»UPDATE_RT 

;SQL> 

UPDATE  RELSHIPS 
SET  SECTR  =  : MAINTR 
WHERE  MAINTR  =  : SECTR 
AND  REL  =  ’RT’ 

AND  SECTR  =  (SELECT  MAINTR  FROM  RELSHIPS 
WHERE  ROWID  =  :ROWID) 

/*  Update  the  reciprocal  associative  entry 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


»UPDATE_UF 

;SQL> 

UPDATE  RELSHIPS 
SET  SECTR  =  : MAINTR 
WHERE  MAINTR  =  : SECTR 
AND  REL  =  'US’ 

AND  SECTR  =  (SELECT  MAINTR  FRCDM  RELSHIPS 
WHERE  ROWID  =  :ROWID) 

/*  Update  the  reciprocal 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


*UPDATE_US 

;SQL> 
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UPDATE  RELSHIPS 
SET  SECre  =  :MAINTR 
WHERE  MAINTR  =  rSECTR 
AND  REL  =  ’UF’ 

AND  SECrm  =  (SELECT  MAINTR  FROM  RELSHIPS 
WHERE  HOWID  =  tROWID) 

/*  Update  the  reciprocal 

;Mess£ige  if  value  not  found  : 

;Must  value  exist  Y/N  : 

Y 


*DELBT 

;SQL> 

;  disconnect  a  hierarchical  relationship  being  deleted  from  the 

;  hierarchical  tree 

UPDATE  RELSHIPS 

SET  MAINTR  =  rSECTR 

WHERE  MAINTR  =  : MAINTR 

AND  REL  =  ’NT’ 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

UPDATE  RELSHIPS 
SET  SECTR  =  rSECTR 
WHERE  SECTR  =  ; MAINTR 
AND  REL  =  ’BT’ 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  RELSHIPS 

WHERE  MAINTR  =  rSECTR  AND  SECTR  =  rMAINTR  AND  REL  =  ’NT’ 

/*  If  there  exists,  deletes  the  reciprocal 

;Messeige  if  value  not  found  r 

;K  t  value  exist  Y/N  r 
N 


*DELNT 

;SQL> 

;  disconnect  a  hierarchical  relationship  being  deleted  from  the 
;  hierarchical  tree 
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UPDATE  RELSHIPS 
SET  MAINTR  =  rSECTR 
WHERE  MAINTR  =  rMAINTR 
AND  REL  =  ’BT’ 

/ 

; Message  if  value  not  found  : 

.'Must  value  exist  Y/N  ; 

N 

UPDATE  RELSHIPS 
SET  SECTR  =  : MAINTR 
WHERE  SECTR  =  : MAINTR 
AND  REL  =  ’NT’ 

/ 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 

DELETE  FROM  RELSHIPS 

WHERE  MAINTR  =  rSECTR  AND  SECTR  =  :MAINTR  AND  REL  =  ’BT’ 
/*  If  there  exists,  deletes  the  reciprocal 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 


*DELRT 

;SQL> 

DELETE  FROM  RELSHIPS 

WHERE  MAINTR  =  rSECTR  AND  SECTR  =  rMAINTR  AND  REL  =  ’RT’ 
/*  If  there  exists,  deletes  the  reciprocal 

; Message  if  value  not  found  r 

;Must  value  exist  Y/N  r 
N 


*DELUF 

;SQL> 

DELETE  FROM  RELSHIPS 

WHERE  MAINTR  =  rSECTR  AND  SECTR  =  rMAINTR  AND  REL  =  ’US’ 
/»  If  there  exists,  deletes  the  reciprx>cal 
ft  go  to  END 

;Message  if  value  not  found  r 
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;Must  value  exist  Y/N  : 
N 


»DEUJS 

;SQL> 

DELETE  FROM  RELSHIPS 

WHERE  MAINTR  =  ;SECTR  AND  SECTR  =  :MAINTR  AND  REL  =  ’UF’ 
/♦  If  there  exists,  deletes  the  reciprocal 

; Message  if  value  not  found  : 

;Must  value  exist  Y/N  : 

N 


Remark:  The  user-triggers  with  prefix  "POST"  are  called  from  a  post¬ 
change  trigger  defined  for  the  field  SecTr  in  this  same  form.  Thus, 
these  user-triggers  are  defined  at  the  form  level  while  the  calling 
trigger  is  defined  at  the  field  level. 

*POST_BT 

;SQL> 

SELECT  ’X’  FROM  DUAL 

WHERE  :MAINCLASSCD  =  :SEOCLASSCD 

/*  If  both  terms  in  a  hierarchical  relat.  do  not  pertain  to  the  same 
/*  class  give  error  message 
/ 

; Message  if  value  not  found  : 

In  a  hierarchical  relationship  both  terms  must  pertain  to  the  same  class. 
;Must  value  exist  Y/N  : 

Y 

SELECT  ’X’  FROM  RELSHIPS 

WHERE  MAINTR  =  :MAINTR  AND  REL  =  »BT’ 

/*  A  term  cannot  have  mor^  than  one  BROADER  TERM  relationship 

/ 

; Message  if  value  not  found  : 

*nie  main  term  already  has  a  BROADER  TERM  relationship.  It  cannot  have 
more. 

;Must  value  exist  Y/N  : 

Y 

SELECT  ’X’  FROM  RELSHIPS 

WHERE  REL  =  ’US’  AND  (MAINTR  =  :MAINTR  (»  MAINTR  =  rSECTR) 

/*  If  either  term  already  has  a  USE  relationship  give  a  not  allowed 
message 

;Nessage  if  value  not  found  : 

*The  main  term  or  the  secondary  term  has  a  USE  relationship. 

;Must  value  exist  Y/N  : 

Y 
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»POST_NT 

:SQL> 

SELECT  'X'  FROM  DUAL 

WHERE  :MAINCLASSCD  =  rSECCLASSCD 

/»  If  both  terms  in  a  hierarchical  relat.  do  not  pertain  to  the  same 
/♦  class  give  error  message 
/ 

; Message  if  value  not  found  : 

In  a  hierarchical  relationship  both  terms  must  pertain  to  the  same  class. 
;Must  value  exist  Y/N  : 

Y 

SELECT  *  FROM  RELSHIPS 

WHERE  SECTR  =  :SECTR  AND  REL  =  ’NT’ 

ft  A  secondary  term  cannot  have  more  than  one  NARROWER  TERM  relationship 

/ 

; Message  if  value  not  found  : 

*The  secondary  term  already  has  a  NARROWER  TERM  relat.  It  cannot  have 
more. 

;Must  value  exist  Y/N  : 

Y 

SELECT  ’X’  FROM  RELSHIPS 

WHERE  REL  =  ’US’  AND  (MAINTR  =  :MAINTR  OR  MAINTR  =  rSECTR) 

ft  If  either  term  already  has  a  USE  relationship  give  a  not  allowed 

message 

; Message  if  value  not  found  : 

♦The  main  term  or  the  secondary  terra  hais  a  USE  relationship. 

;Must  value  exist  Y/N  : 

Y 


♦POSTJUF 

;SQL> 

SELECT  *  FROM  RELSHIPS 

WHERE  MAINTR  =  :MAINTO  AND  REL  =  ’US’ 

ft  The  main  term  cannot  have  a  USED  PC®  relationship  if  it  already  has 
ft  a  USE  relationship 

; Message  if  value  not  found  : 

♦The  main  term  already  has  a  USE  relationship.  It  cannot  have  a  USED  PC® 
rel . 

;Must  value  exist  Y/N  : 

Y 


♦POSTJJS 

;SQL> 

SELECT  ♦  FROM  RELSHIPS 
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WHERE  REL  =  ’US’  AND  MAINTR  =  rMAINTR 

/%  A  main  term  cannot  have  more  than  one  USE  relationship 
; Message  if  value  not  found  : 

♦The  main  term  alreeuiy  has  a  "USE"  relationship. 

;Must  value  exist  Y/N  : 

Y 


Field  SecTr. 

Remark:  This  trigger  executes  some  integrity  operations  related  with  the 
entered  value  of  secon-iary  term.  It  calls  user- triggers  that  were 
defined  at  the  form  level. 

♦♦POST-CHANGE 

/ 

;SQL> 

SELECT  CLASSCD  INTO  SECCLASSCD 
FROM  TERMS 
WHERE  TERM  =  : SECTR 
/ 

; Message  if  value  not  found  ; 

The  secondary  term  does  not  exist. 

;Must  value  exist  Y/N  : 

Y 

#EXEMACRO  CASE  ;REL  IS 

WHEN  'US’  THEN  EXETRG  POSTJJS; 

WHEN  ’UF’  THEN  EXETRG  POSTJUF; 

WHEN  ’BT’  THEN  EXETRG  POST_BT; 

WHEN  ’NT’  THEN  EXETRG  POST_NT; 

END  CASE; 

; Message  if  value  not  found  ; 

;Must  value  exist  Y/N  : 

Y 


Form  A44.  Print  Thesaurus  Terms,  Block  A44 

Remark:  This  user- triggers  are  called  by  a  ceise  statement  placed  in  a 
next  field  key  trigger  (key-nxtfld)  pertaining  to  field  Choice.  They 
exemplify  the  use  of  host  commands  to  execute  a  report  generator  program 
from  inside  a  form. 

♦CHOICEl 

;SQL> 

#CHOST  ’REPORT  A44_l  -s’ 

/ 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 
Y 

#EXEMACRO  NEWn?M  A44; 
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; Message  if  value  not  found 


;Must  value  exist  Y/N  : 
Y 


♦CH0ICE2 

;SQL> 

#OHOST  ’REPCM?T  A44_2  -s’ 

/ 

•.Message  if  value  not  found 

;Must  value  exist  Y/N  : 

Y 

#EXEMACRO  NEWFRM  A44; 

; Message  if  value  not  found 

;Must  value  exist  Y/N  : 

Y 


♦CHOICES 

;SQL> 

#OHOST  ’REPOTT  A44_3  -s’ 

/ 

; Message  if  value  not  found 

;Must  value  exist  Y/N  : 

Y 

#EXEMACRO  NEWFRM  A44; 

; Message  if  value  not  found 

;Must  value  exist  Y/N  : 

Y 


♦CH0ICE4 

;SQL> 

#C«OST  ’REPC«T  A44_4  -s’ 

/ 

; Message  if  value  not  found 

;Must  value  exist  Y/N  : 

Y 

#EXEMACRO  NEWFRM  A44; 


; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 

Y 

Field  Choice. 

Remark:  Hiis  trigger  validates  the  user  choice  and  calls  the  user- trigger 
corresponding  to  the  choice,  to  generate  the  desired  printed  report. 
»»KEY-NXTFLD 
/ 

;SQL> 

SELECT  ’X’  FROM  DUAL 

WHERE  .-CHOICE  IN  (  ’  1  ’ , '2 ’  ,  ’ ' 4 ’  ) 

/ 

; Message  if  value  not  found  : 

Invalid  choice.  Type  1,  2,  3,  or  4  and  Enter. 

;Must  value  exist  Y/N  : 

Y 

#EXEMACRO  CASE  CHOICE  IS 

WHEN  ’1’  THEN  EXETRG  OK^ICEl; 

WHEN  ’2’  THEN  EXETRG  CH0ICE2; 

WHEN  *3’  THEN  EXETRG  CH0ICE3; 

WHEN  ’4’  THEN  EXETRG  aK)ICE4; 

WHEN  OTHERS  THEN  NULL; 

END  CASE; 

; Message  if  value  not  found  : 


;Must  value  exist  Y/N  : 


Appendix  E:  Report  Generation  Files 


File  Rexxart.Bat 

SQL*Report  is  a  Oracle’s  tool  ccmiposed  of  two  programs  used 
together  to  retrieve  information  from  the  database  and  to  format  the 
derived  information  as  desired.  They  are  the  Report  Generator  (RPT)  and 
the  Report  Text  Formatter  (RPT).  The  following  batch  file  was  used  to 
coorxiinate  the  two  programs  and  generate  the  desired  reports  from  inside 
the  forms. 

ECHO  OFF 

REM  File  Name:  REPCKT.BAT  Author:  Lt  Col  Silva  Date:  Feb  1989 
REM  This  file  is  used  by: 

REM  PC«M  A12  TO  PROCESS  THE  A12_1.RPT,  A12_2.RPT,AND  A12_3.RPT 

REM  REPCm  FILES,  WHICH  GENERATE  PROCESSING  SHEETS 

REM 

REM  FOIM  A44  TO  PROCESS  THE  A44_1.RPT,  A44_2.RPT,  A44_3.RPT,  AND 
REM  A44_4.RPT  REPORT  FILES,  WHICH  GENERATE  THESAURUS  TERM  LISTS. 

REN 

REM  IT  CAN  ALSO  BE  USED  TO  PROCESS  ANY  OTHER  .RPT  FILES. 

REM  THE  REPORT  GENERAT(»  PRODUCES  A  INTERMEDIATE  FILE  THAT  HAS  .RPF 
REM  EXTENSION  AND  THE  FINAL  REPORT,  THAT  HAS  A  .LIS  EXTENSION 
CLEAR 
ECHO. 

ECHO  PROCESSING  SHEET  CTMERATION 
ECHO. 

ECHO  Author  Lt  Col  Silva  Feb  1989 

ECHO  Working  . . . 

if  (%!)==( )  goto  ERRCR 

RPT  %1.RPT  %1.RPF  SYSTEM/MANAGER 

RPF  %1.RPF  Xl.LIS  %2 

ECHO. 

ECHO  Output  file  is  %1.LIS 
GOTO  END 
:  ERROI 

ECHO  Syntax  is  "REPCSTT  filename"  [-S) 

ECHO. 

ECHO  filename  is  a  .RPT  file,  without  the  extension 

ECHO  the  repxjrt  output  is  directed  to  filename. lis 

ECHO  -s  if  used,  the  output  is  also  directed  to  the  line  printer 

:END 
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File  A12  l.RPT,  Received  Document  Process  Sheet  Generation 


•REM  PROCESS  SHEET  GENERATICW  -  RECEIVED  DOCUMENTS 

.REM  PRINTS  FROM 

.REM  THE  LAST  DOCUMENT  THAT  HAD  ITS  PROCESSING  SHEET  PRINTED 

.REM  TO 

.REM  THE  LAST  DOCUMENT  ENTERED  IN  THE  SYSTEM 

.REM 

.REM  DEFINE  TAB  STOPS  (TABLES)  Oi  THE  REPORT 

#DT  1  08  73  # 

#DT  2  08  17  18  18  19  20  21  21  22  26  27  27  28  29  55  73  # 

#DT  3  08  44  45  45  46  59  60  72  # 

#dt  4  08  26  28  33  35  73  # 

#DT  5  12  19  20  20  26  32  33  33  54  73  # 

#DT  6  20  20  33  33  # 

#PAGE  0  60 
.REM 

.REM  DECLARE  VARIABLES 

.REM 


.DECLARE 

TODAY 

A9 

.DECLARE 

CLASS IF_NAME 

A12 

.DECLARE 

CLASSIF 

A1 

.DECLARE 

CDRN 

A8 

. DECLARE 

DRN 

99999999 

.DECLARE 

P  SC 

A2 

.DECLARE 

PJX 

A2 

.DECLARE 

P_NUMBER 

A5 

.DECLARE 

P_YEAR 

A2 

.DECLARE 

IDNR 

A5 

.DECLARE 

IDOOMPL 

A13 

.DECLARE 

CRGNAME 

A20 

.DECLARE 

ISSUEDT 

A9 

.DECLARE 

TITLE 

A78 

.DECLARE 

DOCTYPE 

A7 

.DECLARE 

VALIDITY' 

A9 

.DECLARE 

VERIFIER 

A2 

.DECLARE  FIRST_DOC_TO_PRINT  99999999 
.DECLARE  LAST_DOC_TO_PRINT  99999999 

.REM  SELECT  MACROS 

.REM 

.DEFINE  FIRST 

SELECT  LASTNUMBER 

INTO  FIRST_DOC_TO_PRINT 

FROM  SEKTOIBERS 

WHERE  TABLENAME  =  'PRINT  PS  RECEIVED’ 
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DEFINE 


LAST 


SELECT  LASTNUMBER 
INTO  LAST_DOC_TO_PRINT 
FROM  SEWWMBERS 

WHERE  TABLENAME  =  ’DOC  RECEIVED’ 


•DEFINE  DOCUMENT 

•  REM 

SELECT  SYSDATE, 

CLASSIF, 

TO_CHAR(DRN) , 

TO_CHAR{inod(power(DRN,2)  ,97)  ) , 
DRN, 

TO_CHAR(P_SC) , 

TO_CHAR(P_OC) , 

TO_CHAR ( P_NUMBER ) , 
TO_CHAR(P_YEAR) , 

TO_CHAR(IDNR) , 

IDCOMPL, 

C«<^'AME, 

ISSUEDT, 

TITLE, 

DOCTYPE, 

VALIDITY 
INTO  TODAY, 

CLASSIF, 

CE«N, 

VERIFIER, 

DRN, 

P_SC, 

P_OC, 

P_hIUMBER, 

P_YEAR, 

IDNR, 

IDCOMPL, 

CM2WME, 

ISSUEDT, 

TITLE, 

DOCTYPE, 

VALIDITY 

FROM  DOCUMENT 

WHERE  E»?N  >  &FIRST_DOC_TO_PRINT 
AND  E«N  <=  StLAST  DOC  TO  PRINT 


•DEFINE  CLASSIFICATION 

SELECT  CLASS IF_NAME 

INTO  CLASS  IF_NAME 

FROM  CLASSIFICATION 

WHERE  CLASSIF  = 
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(SELECT  CLASSIF 
FTiOM  DOCUMENT 
WHERE  DRN  =  &H?N) 

.REM  DEFINE  PROCEDURAL  MACROS 

.REM 

.DEFINE  BODY 

.EXECUTE  CLASSIFICATICW 
#SP  1 

#T  1  #S  1 
#CEN 

.PRINT  CLASSIF_NAME 
# 

#S  2 

#CEN 

BRAZILIAN\\AIR\\FORCE\\MINISTRY 

# 

#S  1 

#CEN  PROCESSING  SHEET  # 

#S  2 
#TE 
#T  2 

Prot  #; 

.PRINT  P_SC 
#NC 

#NC 

.PRINT  PjX 

#NC 

/ 

#NC 

.PRINT  P_NUMBER 
#NC  / 

#NC 

.PRINT  P_YEAR 

#NC 

DRN: 

.PRINT  CDRN 

.PRINT  VERIFIER 
#S  1  #TE  #T  1 

.PRINT  DOCTYPE 
.PRINT  CLASS IF_NAME 
from 

.PRINT  (*©JAME 
ID  # 

.PRINT  IDNR 

/ 

.PRINT  IDCOMPL 
of 

.PRINT  ISSUEDT 
#S  1  #TE  #T  4 
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Validity: 

.PRINT  VALIDITY 

#NC 

Title: 

#NC 

.PRINT  TITLE 

#S  1 

#TE  #T  1 


#TE 

#T  5  FROM  #NC  !  #NC  TO  #NC  !  #NC  DISPATCH  #N 


#TE  #T  6 

!  #NC 

#NC 

!  #NC 

#NC 

!  #NC 

#NC 

!  #NC 

#NC 

:  #NC 

#NC 

!  #NC 

#NC 

!  #NC 

#NC 

:  #NC 

#NC 

:  #NC 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

!  #NC 

#NC 

:  #Nc 

#NC 

;  #Nc 

#NC 

!  #NC 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

1  #NC 

#KC 

;  #Nc 

#NC 

:  #Nc 

#NC 

!  #NC 

#NC 

;  #Nc 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

!  #NC 

#NC 

:  #Nc 

#NC 

!  #NC 

#NC 

:  #Nc 

#NC 

;  #Nc 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

:  #Nc 

#NC 

#S  1  #TE  #T  1 
#CEN 
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.PRINT  CLASSIF_NAME 
# 

#NP  #TE 
•  REM 

.REM  PROCEDURE  SECTICW 

.REM 

.EXECUTE  FIRST 
.EXECUTE  LAST 
.REPC«T  DOCUMENT  BODY 
.STOP 


CONFIDENTIAL 


BRAZILIAN  AIR  FORCE  MINISTRY 

PROCESSING  SHEET 

Prot  #:  21-23/345  /89  EKN:  89100001  -  8 

BOL  CONFIDENTIAL  from  BAAN  ID  #  221  /  IDFR/89  of  23-FEB-89 
Validity:  16-FEB-94  Title:  THIS  IS  THE  TITLE  OF  DOCUMENT  89100001 


FROM 


TO 


DISPATCH 


CONFIDENTIAL 
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File  A44  3.RPT.  Print  Thesaurus  Terms  by  Hierarchical  Relationship 

.R^  FILE  NAME:  A44_3.RPT 

,REM  PARENT  MODULE  NAME:  MAINTAIN  THESAURUS 

.REM  MODULE  NAME:  PRINT  TERMS 

.R^  REPC«?T  NAME:  C«DER  BY  TERM  HIERARCHICAL  RELATIONSHIP 


.REM  DEFINE  TAB  STOPS  ON  THE  REPORT 

#DT  1  08  73  # 

#DT  2  08  27  66  73  # 

#DT  3  11  18  20  73  # 

#DT  4  08  73  # 

#T  1 

#PAGE  1  90 

.REM  DECLARE  VARIABLES 


.DECLARE 

TODAY 

EDATE 

.SET 

TODAY 

$$DATE$$ 

.DECLARE 

TIMEJOF  REP 

A5 

.SET 

TIME_OF_REP 

$$TIME$$ 

.DECLARE 

CLASSCL 

A2 

.DECLARE 

CLASS 

A20 

.DECLARE 

TEFM 

A50 

.REM  **♦*  VARIABLES 

USED  TO  BREAK 

.DECLARE 

CXXJNTER 

99 

•  SET 

COUhJTER 

6 

.DECLARE 

PAGE  NO 

99 

.SET 

PAGE_NO 

1 

.DECLARE 

MAX_LINES 

99 

.SET 

MAX  LINES 

62 

.REM  ****  VARIABLES  USED  TO  BREAK  CLASS  NAME 
.DECLARE  SAVEJCLASSCD  A2 
.SET  SAVE_CLASSCD  ’»*’ 

.REM  SELECT  MACROS 

.DEFINE  SEL  TERM 


SELECT!  LPAD(  ’  ’,3*LEVEL)  \  \  LEVEL  MAINTR 

INTO  TERM 
FROM  RELSHIPS 

CONNECT  BY  PRICK  MAINTR  r  SECTR  AND  REL  =  *BT’ 
START  WITH  MAINTR  =  ’BOOT’ 

AND  RELr’BT’ 

AND  SECTR  IS  NULL 
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.REM  DEFINE  PROCEDURAL  MACROS 

.DETINE  BREAK_PAGE 

. &label 1 

.IF  &£XXJNTER<&MAX_LINES  THEN  label2 
.SET  COUNTER  6 

.REM  the  heading  has  5  lines 
.ADD  PAGEJJO  PAGE_NO  1 
.NP 
.HEAD 
.&label2 

.ADD  COUNTER  COUNTER  1 


.defint:  head 

#TE 
#T  1 

#CEN 

THESAURUS  REPCKT  A44_3  -  C«DER  BY  TERM  HIERARCHICAL  ASSOCIATION 
# 

#TE 
#T  2 

.PRINT  TODAY 
.PRINT  TIMEJDFJREP 
#NC 
PAGE 

.PRINT  PAGE_NO 

#TE 
#S  1 
#T  3 

Level 

#NC 

Term 

#S  1 

.BC»Y 


.DEFINE  BCDY 


#TE 
#T  4 

.BREAK_PAGE 

#CL 

.FPRINT  TERM 

« 

#NC 
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FOOT 


.DEFINE 
#TE 
#S  3 

#CUL  END  OF  REPC«T  # 

«  * 

.REM  ttt*t*t*t*ttt*****t******ttttt***t**tt**ttt*tt***tt 

.REM  PROCEDURE  SECTION 

.REPCRT  SEL_TEra^  BODY  HEAD  FOOT 
.STOP 


File  A44  4.RPT,  Print  Thesaurus  Terms  Giving  all  Relationshi 


.REM  FILE  NAME:  A44. 

_4.RPT 

.REM  PARENT  MODULE  NAME:  MAINTAIN  THESAURUS 

.REM  MODULE  NAME:  PRINT  TERMS  ' 

.REM  REPORT  NAME:  CRDER  BY  TERM  AND  RELATICWSHIPS  ! 

.REM 

DEFINE  TAB  STOPS  (TABLES)  CN  THE  REPt»T 

#DT  1  1 

08  73  # 

#DT  2  < 

08  27  66  73 

# 

#DT  3  ( 

08  33  35  73 

# 

#DT  4 

35  43  45  73 

# 

#DT  5 

11  73  # 

#T  1 

#PAGE  1  1 

90 

.REM 

DECLARE  VARIABLES 

1 

.DECLARE 

TODAY 

EDATE 

.SET 

TODAY 

$$DATE$$ 

.DECLARE 

TIME  OF  REP 

A5 

.SET 

TIME_OF_REP 

$$TIME$$ 

.DECLARE 

CLASSCD 

A2 

.DECLARE 

CLASS 

A20 

.DECLARE 

TERM 

A25 

. DECLARE 

REL 

A2 

.DECLARE 

RELNAME 

A8 

. DECLARE 

SECTERM 

A25 

.DECLARE 

NOTE 

A60 

.REM  t**t  VARIABLES 

USED  TO  BREAK  PAGES 

.DECLARE  COUNTER 

99 

.SET 

COUNTER 

9 

.DECLARE 

PAGE_NO 

99 

.SET 

PAGE_NO 

1 

.DECLARE 

MAX_LINES 

99 

.SET 

MAX_LINES 

62 

1 

i 

i 
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.REM  SEl£Crr  MACROS 

.DEFINE  SELJTERM 

SELECT  CLASSCD,  TERM 
INIO  CLASSCD,  TERM 
FROM  TERMS 
a®ER  BY  TERM,  CLASSCD 


.DEFINE  SEL_CLASS 

SELECT  CLASS 
INTO  CLASS 
FROM  CLASSES 
WHERE  CLASSCD  =  &CLASSCD 


.DEFINE  SEL_RELATIC»JSHIPS 

SELECT  REL,  SECTR 

INTO  REL,  SECTERM 

FROM  RELSHIPS 

WHERE  MAINTR  =  &TERM 

ORDER  BY  REL,  SECTR 


.DEFINE 

SELECT 

INTO 

FROM 

WHERE 


.DEFINE 

SELECT 

INTO 

FROM 

WHERE 


SEL_RELNAME 
RNAME 
RELNAME 
RELNAME 
REL  —  &REL 


SEL_NOTES 

NOTE 

NOTE 

NOTES 

TERM  =  &TEFJM 


.REM  DEFINE  PROCEDURAL  MACROS 

.DEFINE  BREAKJPAGE 
.&labell 

.IF  atOOUNTER<&MAX_LINES  THEN  label2 
.SET  COUNTER  9 

.REM  set  counter  with  the  number  of  lines  in  the  header 

.REM  pliis  the  top  and  bottom  margins 

.ADD  PAGE_NO  PACE_NO  1 

.NP 

.HEADl 
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.&label2 

.ADD  COUNTER  COUNTER  1 


.DEFINE  SEL_RELATIONSHIPS_BODY 

#TE 
#T  4 

.EXECUTE  SEL_RELNAME 
.PRINT  RELNAME 
#NC 

.PRINT  SECTERM 
#NC 

.BREAK  PAGE 


.  DEFI  NT  SEL_NOTESJBODY 

#TE 
#T  5 

.PRINT  NOTE 
#NC 

.BREAK  PAGE 


.DEFINE  HEADl 


#T  1 

#CEN 

THESAURUS  REPCKT  A44_4  -  C«DER  BY  TERM  AND  RELATICWSHIPS 
# 

#TE 
#T  2 

.PRINT  TODAY 
.PRINT  TIME_OF_REP 
#NC 
PAGE 

.PRINT  PAGE_NO 

#TE 
#S  1 
#T  3 

Term 

#NC 

Class  Number  &  Clsiss  Name 
#NC 

\  \  \Scope  Note 

#NC 

RelationX  \Secondary  Term 

#S  1 

•  • 

.DEFINE  HEAD2 
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HEADl 

BCa)Y 


.DEFINE  BODY 

. EXECUTE  SEL_CLASS 

#TE 

#T  3 

.raiNT  TERM 
#NC 

.PRINT  CLASSCD 
.PRINT  CLASS 
#NC 

.REM  the  following  nested  report  gets  the  relationships 
.REPCRT  SEL_NOTES  SEL_NOTESJBODY 

.REPOn-  SEL_RELATIONSHIPS  SEL_RELATIONSHIPS_BODY 
.BREAK  PAGE 


.DEFINE  FOOT 

#TE 

#S  3 

#CUL  END  OF  REPC«T  # 

*  • 

.REM 

.REM  PROCEDURE  SECTIW 

.REM 

.RETWr  SELJTERM  BODY  HEAD2  FOOT 
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